XSchema Spec Section 2.2, Draft 1

[Paul Prescod]

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 
SGML does.

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.

I propose:

XSC:name NAME -> required and must be unique among element constraint 
declarations.

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)

 Paul Prescod


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)