Lists Home |
Date Index |
- From: Paul Prescod <firstname.lastname@example.org>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>
- Date: Wed, 10 Jun 1998 07:01:09 -0400 (EDT)
On Wed, 10 Jun 1998, Simon St.Laurent wrote:
> Element declarations in XSchemas are made using the XSC:ElementDecl element
> and its contents:
We need to align this terminology with XML. We certainly are NOT
declaring individual elements!.
One way to fix this up would be to call these "Element Type Declarations".
But philosophically, you have to ask yourself: "Are we really declaring
element types?" This would be more right than what we have, but still not
quite right, in my book. The word "type" implies a "type system", which
we are probably not interested in. And the word "declaration" implies
that this is the one and only place that the element type is "declared".
That made sense in DTD-land, but in schema land, I think the terminology
is a little out of whack. In my mind, the element type exists long before
the XSchema processor sees it. And if a document has no XSchema the
element types still conceptually exist.
I suggest "element constraint declaration" and "attribute constraint
declaration" with the GIs XSC:Element and XSC:Attribute. That implies
that this is the one and only one declaration of this particular
constraint -- which is a tautology.
> <!ELEMENT XSC:ElementDecl (XSC:Doc?, (XSC:Ref | XSC:Choice | XSC:Seq |
> XSC:Empty | XSC:Any | XSC:PCData | XSC:Mixed), XSC:AttDef*)>
> <!-- id is the element name -->
> <!ATTLIST XSC:ElementDecl XSC:id ID #REQUIRED >
I don't have time to go into this in detail, but I would urge you to
consider aligning the handling of content models with regular expression
theory. For instance, consider allowing XSC:Any *anywhere* in a content
model. This will go a long way towards the flexibility that people need
when they ask for "inheritance."
Because of the festering hole that is XML whitespace (if there is a clean
solution, I don't know it), the situation with XSC:Mixed and XSC:Pcdata
is more complicated. Will XSchema's be used to guide the ignoring of
whitespace? If so, we should be constrained to the simple models XML
allows. If not, we could mix in XSC:Pcdata and XSC:Mixed anywhere, as
I think that we should go for it: make the whole thing simple, orthogonal
and consistent. This is an experimental language, right? If we can't try
out potential over-simplifications here, then when can we try them out?
> The XSC:id attribute identifies the name of the element, and is required.
I don't think that ID/IDREF is going to be powerful enough for us,
unfortunately. We will want to be allowed to reuse the same name for and
element and an attribute, for instance. So the name need only be unique
across a particular type. XML doesn't support this well, but a "linking
schema" language could (in the future) or some future version of XSchema
could support it directly. Michael Sperberg-McQueen described a nice
syntax for describing these kinds of constraints once.
XSC:name NAME -> required and must be unique among element constraint
XSC:longname CDATA -> for use in XML editors, viewers and other places
where a longer name might be appropriate. (e.g. never referenced, always
just used for output)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)