XSchema Spec Section 2.2, Draft 1

[John Cowan]

Paul Prescod wrote:

> We need to align this terminology with XML. We certainly are NOT
> declaring individual elements!.

I agree, although the XML spec does use the term "ElementDecl" for
the syntactic nonterminal in question.  (The XSchema names are
taken, for the most part, directly from the XML spec.)
 
> 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.

I disagree.  Element types are "types" in the sense of a type vs.
token distinction; the elements themselves (in document instances)
are tokens.  This use of "type" does not imply any type system:
the types of English, e.g., do not constitute a system in any
meaningful sense (more like a historical rag-bag).

> And the word "declaration" implies
> that this is the one and only place that the element type is "declared".

Again, I disagree.  There is a document commonly called the
"Declaration of Independence", but that is not the unique repository
of claims to independence, or even the United States' claims.

You will tell me that the words "type" and "declaration" have specific
meanings as terms of art in computer science.  I reply that this
is not computer science, in the sense commonly understood by that term.

> 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."

I think that this suggestion (loosening what is allowed in a content
model) has some merit to it, although IMHO it would need to be
a hypothetical AnyElement rather than true ANY, to preserve
unambiguous parsing.
 
> Because of the festering hole that is XML whitespace (if there is a clean
> solution, I don't know it),

What "festering hole"?  XML's solution is simple: all whitespace is
meaningful, just as all non-whitespace is meaningful.  If a particular
application chooses to ignore whitespace in certain circumstances,
it is free to do so, just as it can ignore letter case, or even
(*gasp*) ignore element structure or attribute values.

> 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 don't claim familiarity with SGML theory or practice, but I note
the existence of something called the "SGML mixed content problem".
As far as I can see, the standard solutions to this problem are
exactly what XML mandates: the simple (#PCDATA | foo | bar)* content
models.

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

See my earlier posting on attributes.  In particular, the attribute
"foo" of element BAR and the attribute "foo" of element BAZ need
have nothing else in common, so even having separate IDspaces for
names and attributes isn't enough.  The current XSchema draft
dodges the problem by embedding the attributes (but may be
extended to allow cross-referencing via an ID that is *not* the
attribute name).

-- 
John Cowan	http://www.ccil.org/~cowan		cowan at ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

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)