- 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