- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 18 May 2007 16:39:37 -0400
- To: "Michael Kay" <mike@saxonica.com>
- Cc: "'Pete Cordell'" <petexmldev@tech-know-ware.com>, xmlschema-dev@w3.org
Michael Kay writes: > It's interesting to ask whether vocabularies such as XSLT and XML Schema > follow the rule that a given element name or attribute name has the same > syntax and semantics wherever it appears. Yes indeed. First of all, I don't love the schema choice on architectural grounds, but it's more convenient for users I think. If schema were intended only for mechanical authoring, I think I would argue that <elementReference> should be distinct from <element> (or if you prefer, <elementDeclaration>). Actually, I think the current schema language hits a middle ground that's the worst of both worlds. What I think human authors really want is: <element name="width" type="integer" minInclusive="0" maxInclusive="100"/> There's nothing in the abstract language that prevents this, but this was felt to be be not good markup, because the constraints on what's legal are so complex (maxInclusive is presumably prohibited for complexTypes, subtypes of string, etc.) So, we have all that goofy <complexContent> stuff because it's good markup that can be validated without the co-constraints that were missing in Schema 1.0, yet, in the interest of simplicity for human authors, we have <element> serving multiple purposes. As you mentioned in an earlier note, I can never remember the syntax without a cheat sheet, even after all these years working with it. FWIW, I did at least argue against some of the more baroque markup, and may even have formally voted against it. In the interest of moving ahead, I did agree to concur when the majority of others settled on the current compromise. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
Received on Friday, 18 May 2007 21:24:34 UTC