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.