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.