what is <classRef> supposed to do for attr classes?
I'm a bit confused by the use of PureODD's <classRef>.
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
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.
I think #3 is interesting: 3. content/descendent::classRef[ starts-with( @key, 'att.') ] If a classRef appears within an alternate[@maxOccurs="1"], then presumably it _should_ mean that the element would either have those attributes, or it would allow another descendant element, but not both. That would be kind of useful, although horrible to process, and presumably better achieved with Schematron. Cheers, Martin On 2018-04-27 12:33 PM, Lou Burnard wrote:
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.
Yup. Glad you pointed that out. Because it is not insane, even if a bad idea, to allow references to attributes in <content>. That's how RELAX NG handles it. This: | <content> | <alternate minOccurs="1" maxOccurs="1"> | <classRef key="att.datable.iso" include="when-w3c"/> | <dataRef name="xs:date"/> | </alternate> | </content> makes perfect sense to me, and can be represented in RELAX NG as: | ( att.datable.w3c.attribute.when | xsd:date ) No reason, I don't think, that the plurals or <sequence> wouldn't work, either, but that would be a heavy load on the Stylesheets.[1] Notes ----- [1] Note that in RELAX NG, "att.datable.w3c.attribute.when*" is valid, but "xsd:date*" is not. I guess that's because RELAX NG knows that an attribute cannot be repeated, but does not know how to repeat a string. (Need to use the 'list' construct if you want to repeat a string.)
I think #3 is interesting:
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
If a classRef appears within an alternate[@maxOccurs="1"], then presumably it _should_ mean that the element would either have those attributes, or it would allow another descendant element, but not both. That would be kind of useful, although horrible to process, and presumably better achieved with Schematron.
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks. On 27/04/18 22:24, Syd Bauman wrote:
Yup. Glad you pointed that out. Because it is not insane, even if a bad idea, to allow references to attributes in <content>. That's how RELAX NG handles it.
This: | <content> | <alternate minOccurs="1" maxOccurs="1"> | <classRef key="att.datable.iso" include="when-w3c"/> | <dataRef name="xs:date"/> | </alternate> | </content> makes perfect sense to me, and can be represented in RELAX NG as: | ( att.datable.w3c.attribute.when | xsd:date )
No reason, I don't think, that the plurals or <sequence> wouldn't work, either, but that would be a heavy load on the Stylesheets.[1]
Notes ----- [1] Note that in RELAX NG, "att.datable.w3c.attribute.when*" is valid, but "xsd:date*" is not. I guess that's because RELAX NG knows that an attribute cannot be repeated, but does not know how to repeat a string. (Need to use the 'list' construct if you want to repeat a string.)
I think #3 is interesting:
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
If a classRef appears within an alternate[@maxOccurs="1"], then presumably it _should_ mean that the element would either have those attributes, or it would allow another descendant element, but not both. That would be kind of useful, although horrible to process, and presumably better achieved with Schematron.
We shouldn't let the tail (RELAXNG) wag our dog, methinks.
Haven't we been doing precisely that with DTDs for years? I'd rather be wagged by RELAXNG than DTD. On 2018-04-27 02:28 PM, Lou Burnard wrote:
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks.
On 27/04/18 22:24, Syd Bauman wrote:
Yup. Glad you pointed that out. Because it is not insane, even if a bad idea, to allow references to attributes in <content>. That's how RELAX NG handles it.
This: | <content> | <alternate minOccurs="1" maxOccurs="1"> | <classRef key="att.datable.iso" include="when-w3c"/> | <dataRef name="xs:date"/> | </alternate> | </content> makes perfect sense to me, and can be represented in RELAX NG as: | ( att.datable.w3c.attribute.when | xsd:date )
No reason, I don't think, that the plurals or <sequence> wouldn't work, either, but that would be a heavy load on the Stylesheets.[1]
Notes ----- [1] Note that in RELAX NG, "att.datable.w3c.attribute.when*" is valid, but "xsd:date*" is not. I guess that's because RELAX NG knows that an attribute cannot be repeated, but does not know how to repeat a string. (Need to use the 'list' construct if you want to repeat a string.)
I think #3 is interesting:
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
If a classRef appears within an alternate[@maxOccurs="1"], then presumably it _should_ mean that the element would either have those attributes, or it would allow another descendant element, but not both. That would be kind of useful, although horrible to process, and presumably better achieved with Schematron.
Me too, but I'd rather not be wagged at all On 27/04/18 23:07, Martin Holmes wrote:
We shouldn't let the tail (RELAXNG) wag our dog, methinks.
Haven't we been doing precisely that with DTDs for years? I'd rather be wagged by RELAXNG than DTD.
On 2018-04-27 02:28 PM, Lou Burnard wrote:
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks.
On 27/04/18 22:24, Syd Bauman wrote:
Yup. Glad you pointed that out. Because it is not insane, even if a bad idea, to allow references to attributes in <content>. That's how RELAX NG handles it.
This: | <content> | <alternate minOccurs="1" maxOccurs="1"> | <classRef key="att.datable.iso" include="when-w3c"/> | <dataRef name="xs:date"/> | </alternate> | </content> makes perfect sense to me, and can be represented in RELAX NG as: | ( att.datable.w3c.attribute.when | xsd:date )
No reason, I don't think, that the plurals or <sequence> wouldn't work, either, but that would be a heavy load on the Stylesheets.[1]
Notes ----- [1] Note that in RELAX NG, "att.datable.w3c.attribute.when*" is valid, but "xsd:date*" is not. I guess that's because RELAX NG knows that an attribute cannot be repeated, but does not know how to repeat a string. (Need to use the 'list' construct if you want to repeat a string.)
I think #3 is interesting:
3. content/descendent::classRef[ starts-with( @key, 'att.') ]
If a classRef appears within an alternate[@maxOccurs="1"], then presumably it _should_ mean that the element would either have those attributes, or it would allow another descendant element, but not both. That would be kind of useful, although horrible to process, and presumably better achieved with Schematron.
LB> Yes. This already happens if you include the module tei but not LB> the module in which the class you're referencing is declared, in LB> the case of predeclared classes. Right. And allowing <classRef key="model.*"> directly inside <schemaSpec> makes this sort of event, which would usually be a mistake, more likely. So the question is, does the benefit of being able to say "I'm going to use this class even though I have not included the module in which it is defined" (because if I had included the model in which it is defined, the <classRef> would be completely superfluous) outweigh the harm caused by folks using it incorrectly (i.e., to refer to elements that they think they are getting, but are not defined). My instinct is "no", but others may think differently. LB> It would never have occurred to me to use @expand for an LB> attribute class, but hey by all means make it more explicit that LB> doing so is bonkers. Roger. Makes a lot of sense to me (to make the prose explicit that it's for model classes). However, <classRef> does not have a type="model|atts", so the only way to actually test this to make it invalid is to test if the @key starts with "att.", which works perfectly well for TEI P5, but a customization or a non-TEI language defined by ODD might not have that naming convention. (And, I suppose, could even be silly enough to have a model class named "att.*", but if you do that you deserve confusion.) LB> I guess we're seeing here the fallout from not defining attclass LB> and modelclass as two different kinds of thing. Yup.
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks.
Yes, I think you have exactly the right analysis; but I come to the exact opposite conclusion: RELAX NG allows references to attributes in content because it considers both attributes and elements alike as patterns. Wouldn't it be nice if we had that same capability in ODD? And I don't think it would be that crazy to do in Pure ODD. It would just mean that membership in attribute classes, or more precisely the ability to have an attribute, would be expressed using <attRef> (or <classRef>) inside <content>.[1] This would increase the expressive power of ODD quite a bit. (I think it takes care of those co-occurrence constraints that are based on the presence of an attribute, but not those that depend on its value.) As a corollary, we might say that <classes> would be used only for model classes, which would make use of <classes> cleaner and easier for users to understand. But we would not have to say that. Note ---- [1] Might want to rename <content> to <structure> or some such.
Two quick reactions, cos its bedtime here. 1. You might want to use classRef inside schemaSpec to restrict the components (elements or attributes) the class supplies, by means of include or exclude. I can't think of any other sensible use (and I dont know for sure if that one even works) 2. The distinction ODD makes between elements and attributes is sort of built into its DNA. It goes back to the very first debates in the very first metalanguage committee. I think reconceptualising ODD as RELAXNG would not be a very smart move (remember we're trying to keep clear blue water between ODD and other schema languages). Maybe when P6 comes along... On 27/04/18 23:11, Syd Bauman wrote:
LB> Yes. This already happens if you include the module tei but not LB> the module in which the class you're referencing is declared, in LB> the case of predeclared classes.
Right. And allowing <classRef key="model.*"> directly inside <schemaSpec> makes this sort of event, which would usually be a mistake, more likely. So the question is, does the benefit of being able to say "I'm going to use this class even though I have not included the module in which it is defined" (because if I had included the model in which it is defined, the <classRef> would be completely superfluous) outweigh the harm caused by folks using it incorrectly (i.e., to refer to elements that they think they are getting, but are not defined). My instinct is "no", but others may think differently.
LB> It would never have occurred to me to use @expand for an LB> attribute class, but hey by all means make it more explicit that LB> doing so is bonkers.
Roger. Makes a lot of sense to me (to make the prose explicit that it's for model classes). However, <classRef> does not have a type="model|atts", so the only way to actually test this to make it invalid is to test if the @key starts with "att.", which works perfectly well for TEI P5, but a customization or a non-TEI language defined by ODD might not have that naming convention. (And, I suppose, could even be silly enough to have a model class named "att.*", but if you do that you deserve confusion.)
LB> I guess we're seeing here the fallout from not defining attclass LB> and modelclass as two different kinds of thing.
Yup.
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks. Yes, I think you have exactly the right analysis; but I come to the exact opposite conclusion:
RELAX NG allows references to attributes in content because it considers both attributes and elements alike as patterns. Wouldn't it be nice if we had that same capability in ODD?
And I don't think it would be that crazy to do in Pure ODD. It would just mean that membership in attribute classes, or more precisely the ability to have an attribute, would be expressed using <attRef> (or <classRef>) inside <content>.[1] This would increase the expressive power of ODD quite a bit. (I think it takes care of those co-occurrence constraints that are based on the presence of an attribute, but not those that depend on its value.)
As a corollary, we might say that <classes> would be used only for model classes, which would make use of <classes> cleaner and easier for users to understand. But we would not have to say that.
Note ---- [1] Might want to rename <content> to <structure> or some such.
I forgot to point out that classRef lacks a @type attribute because it assumes you're smart enough to get that information from the @type of the classSpec which is being referenced... On 27/04/18 23:23, Lou Burnard wrote:
Two quick reactions, cos its bedtime here.
1. You might want to use classRef inside schemaSpec to restrict the components (elements or attributes) the class supplies, by means of include or exclude. I can't think of any other sensible use (and I dont know for sure if that one even works)
2. The distinction ODD makes between elements and attributes is sort of built into its DNA. It goes back to the very first debates in the very first metalanguage committee. I think reconceptualising ODD as RELAXNG would not be a very smart move (remember we're trying to keep clear blue water between ODD and other schema languages). Maybe when P6 comes along...
On 27/04/18 23:11, Syd Bauman wrote:
LB> Yes. This already happens if you include the module tei but not LB> the module in which the class you're referencing is declared, in LB> the case of predeclared classes.
Right. And allowing <classRef key="model.*"> directly inside <schemaSpec> makes this sort of event, which would usually be a mistake, more likely. So the question is, does the benefit of being able to say "I'm going to use this class even though I have not included the module in which it is defined" (because if I had included the model in which it is defined, the <classRef> would be completely superfluous) outweigh the harm caused by folks using it incorrectly (i.e., to refer to elements that they think they are getting, but are not defined). My instinct is "no", but others may think differently.
LB> It would never have occurred to me to use @expand for an LB> attribute class, but hey by all means make it more explicit that LB> doing so is bonkers.
Roger. Makes a lot of sense to me (to make the prose explicit that it's for model classes). However, <classRef> does not have a type="model|atts", so the only way to actually test this to make it invalid is to test if the @key starts with "att.", which works perfectly well for TEI P5, but a customization or a non-TEI language defined by ODD might not have that naming convention. (And, I suppose, could even be silly enough to have a model class named "att.*", but if you do that you deserve confusion.)
LB> I guess we're seeing here the fallout from not defining attclass LB> and modelclass as two different kinds of thing.
Yup.
RELAXNG allows references to atributes in content because it considers both attributes and elements alike as patterns. In ODD we tend to think that elements and attributes are different kinds of beast. We shouldn't let the tail (RELAXNG) wag our dog, methinks. Yes, I think you have exactly the right analysis; but I come to the exact opposite conclusion:
RELAX NG allows references to attributes in content because it considers both attributes and elements alike as patterns. Wouldn't it be nice if we had that same capability in ODD?
And I don't think it would be that crazy to do in Pure ODD. It would just mean that membership in attribute classes, or more precisely the ability to have an attribute, would be expressed using <attRef> (or <classRef>) inside <content>.[1] This would increase the expressive power of ODD quite a bit. (I think it takes care of those co-occurrence constraints that are based on the presence of an attribute, but not those that depend on its value.)
As a corollary, we might say that <classes> would be used only for model classes, which would make use of <classes> cleaner and easier for users to understand. But we would not have to say that.
Note ---- [1] Might want to rename <content> to <structure> or some such.
LB> 1. You might want to use classRef inside schemaSpec to restrict the LB> components (elements or attributes) the class supplies, by means of LB> include or exclude. I can't think of any other sensible use (and I LB> dont know for sure if that one even works) Seems reasonable, and for attribute classes the Guidelines have 2 examples of exactly this use. It is not exemplified for elements. LB> 2. The distinction ODD makes between elements and attributes is LB> sort of built into its DNA. It goes back to the very first LB> debates in the very first metalanguage committee. I think LB> reconceptualising ODD as RELAXNG would not be a very smart move LB> (remember we're trying to keep clear blue water between ODD and LB> other schema languages). Maybe when P6 comes along... Yes, I remember that we're trying to be schema language agnostic, but I also know that I don't understand why, and I think it is overall a bad idea. (And I forgive those in the first metalanguage committee[1] their transgression: I don't think the idea that elements and attributes could be validated using similar syntax, and be dependent on one another had yet been suggested, let alone implemented in a clean, easy-to-use, readily available standard schema language; heck, I don't think even MSMcQ had yet floated the idea that having a different syntax for schemas (i.e., DTD language) than for document instances (i.e., pointy brackets) is, well, kinda pointless.)
I forgot to point out that classRef lacks a @type attribute because it assumes you're smart enough to get that information from the @type of the classSpec which is being referenced...
Oooh. Good point. Thank you. I had completely forgotten about that. (Guess I'm not smart enough; well, now I am. :-) Notes ----- [1] David Barnard, Lou Burnard, Roberto Cencioni, David Durand, Jean-Pierre Gaspart, Doug Hamilton, Nancy Ide, Sandra Mamrak, Eugenio Picchi, Lynne Price, Michael Sperberg-McQueen, Frank Tompa, Giovanni Varile, and Nino Varile.
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"
Hmm. Guess that makes sense, if a bit dangerous in that it makes it more likely I include a reference to a model full of references to undefined elements. (E.g., by having <classRef key="model.personNamePart"/> without <moduleRef key="namesdates"/>.)
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.
In which case these should be addressed by (b), below.
4. classRef[ starts-with( @key, 'att.' ][ @expand ] )
See documentation for @expand
I did. Although it never mentions "element" (as opposed to "attribute"), it explicitly refers to the content model, which in your mind (as indicated by your response to my postscript and #2 & #3) should not contain references to attributes. That said, nothing at the moment prevents an ODD writer from putting <classRef key="att.handFeatures" expand="alternate"/> as a child of <schemaSpec>, and expect that through some magic only 1 of the hand feature attributes could be used on an element that included <memberOf key="att.handFeatures"/>. Not sure what a user who puts in <classRef key="att.handFeatures" expand="sequenceRepeatable"> thinks is going to happen, since attributes cannot have sequence and cannot be repeated, but she might believe they would all be required, I guess. So I'm inclined to think the documentation for @expand should be explicit (that it is for model classes, not attribute classes), and that a validation check (probably a Schematron rule) should warn you if you try to use @expand when key="att.*".
Stylesheets code that does the right thing is a wonderful concept, whose time has come.
Soon, I hope. I actually ran across this while researching Stylesheets tickets.
On 27/04/18 21:58, Syd Bauman wrote:
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" Hmm. Guess that makes sense, if a bit dangerous in that it makes it more likely I include a reference to a model full of references to undefined elements. (E.g., by having <classRef key="model.personNamePart"/> without <moduleRef key="namesdates"/>.)
Yes. This already happens if you include the module tei but not the module in which the class you're referencing is declared, in the case of predeclared classes.
So I'm inclined to think the documentation for @expand should be explicit (that it is for model classes, not attribute classes), and that a validation check (probably a Schematron rule) should warn you if you try to use @expand when key="att.*".
It would never have occurred to me to use @expand for an attribute class, but hey by all means make it more explicit that doing so is bonkers. I guess we're seeing here the fallout from not defining attclass and modelclass as two different kinds of thing.
participants (3)
-
Lou Burnard -
Martin Holmes -
Syd Bauman