WeBWorK: be less discriminatory about when to create $webwork-representations…

[Alex-Jordan]

…-dir publisher variable

This addresses an issue reported by Kyle in -support. All his webwork have only text children, instead of element children. It caused the `$webwork-representations-dir variable to be empty.

[rbeezer]

Nice catch! Did not see that one coming. Merged as-is.

Did you do an audit of other places we need to be careful about confusion with <webwork/>?

And...welcome back!

[Alex-Jordan]

And...welcome back!

Not so fast! Maybe in summer :)

Did you do an audit...

I hadn't, but this sounded like just low enough hanging fruit that I tried to do one just now. But I'm quitting for now until we can catch up with the schema first.

I think that ideally, there are these mutually exclusive flavors of a <webwork>:

1. Absolutely no nodes or attributes, for generating "WeBWorK".
2. Only text nodes, no elements.
3. Only element nodes, no text nodes (except trivial white space). There are requirements about which elements, of course.
4. Has @source.
5. Has @copy.
6. Has @local.

And then for 2-6, there are optional attributes can be @xml:id , @label, @component, @seed. Except maybe now we do not need @label? I'm unsure if that has a role to play anymore, or it's all based on the parent exercise's @label. We do still use @xml:id, as the target of a @copy.

The current schema doesn't mention @local at all. And it allows having element children but also having a @copy, which I don't think makes sense.

The point is if I can rely on the schema, then the XSLT could become simpler in some places by being more lax. I don't mind editing the schema in a way that I think makes sense. And I could test a new proposed schema on the sample chapter, and a project or two (ORCCA, APEX). Would that be sufficient?