On 27/04/18 20:14, Syd Bauman wrote:
I'm a bit confused by the use of PureODD's <classRef>. Dearie me.
When the class being referred to is a model class, it would seem the intent is that it be used form within <content>, and the members of that model class can appear at this point in the content model. And, indeed, all 25 examples of <classRef key="model.*"> occur as descendants of <content>.
When the class being referred to is an attribute class, it would seem the intent is that the attributes defined by the class are available to be used, as a group, by reference to the class name on classes/memeberOf/@key. And, indeed, all 3 examples of
But what does it *mean* (and what *happens*) when <classRef> is used in other circumstances in which it is allowed by the schema:
1. schemaSpec/classRef[ starts-with( @key, 'model.') ]
This means (much like elementRef as a direct child of schemaSpec) "if you've got a definition for that class knocking around in your @source, we're going to use it"
2. content/classRef[ starts-with( @key, 'att.') ]
This shouldn't happen. It is redundant with making the parent element a member of the class concerned.
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
Same again.
4. classRef[ starts-with( @key, 'att.' ][ @expand ] )
See documentation for @expand
I think it is incumbent upon us for each of these combinations to either
a) say what it means, and perhaps even have Stylesheets code that does the right thing,
Stylesheets code that does the right thing is a wonderful concept, whose time has come.
OR b) say it is not allowed (and have a validity check that prevents it).
Less keen on this one.
P.S. I have briefly tested #2, and it appears to do exactly what I expected: the attributes defined by the class referenced are allowed on that element. @include did not work, though. (All attrs were included in schema, not just the included one.)
Interesting. It's probably a relic of some earlier code -- not exercised by the Guidelines, as you point out, so forgotten.