xml-dev - Re: XSchema: multiple proposals

[John Cowan <cowan@locke.ccil.org>]

Toby Speight wrote:

> I can understand that you like the symmetry between Choice an Seq,
> but I don't like the way that Choice can be an immediate descendent
> of Choice, or Seq an immediate descendent of Seq - it adds no extra
> value, and increases the number of ways of representing a particular
> schema.  This makes comparing XSchemas more difficult (not a design
> goal, I know, but I see no reason to gratuitously complicate things).

[examples snipped]

XML DTDs allow the same flexibility, with content models like
"(A | (X | Y))" versus "(A | X | Y)" and similarly for sequences.

My proposal states: "It is not possible to reconstruct the exact DTD
used to create an XSchema, but a functionally equivalent DTD can be
reconstructed."  I think this difference comes under that heading.
I agree that having multiple ways of representing the same thing
is a Bad Thing.

> [*] No bias - I was just more rushed when John's appeared.

So get cracking!  :-)
 
> > <!ELEMENT NotationType>
> > <!ATTLIST NotationType values NMTOKENS #REQUIRED>
> > <!ELEMENT Enumeration>
> > <!ATTLIST Enumeration values NMTOKENS #REQUIRED>
> 
> I like that (more than the current proposal).

I find NMTOKENS (and to a lesser degree the other plural attribute
types) obnoxious. They place an additional parsing burden on 
applications that use them, since AFAIK no parser offers to split the 
attribute values up (and only a DTD-aware parser could do so).  If 
something is genuinely one-to-many, then element substructure is more
useful for representing it.

> I have a preference for ID/IDREF, as this works in ordinary XML or
> SGML systems, without requiring XLink support.  But it raises the
> question: how to support linked XSchemas?

How about with external parsed entities?  Since we would want to
link in whole XSchemas, not just parts of them, as a rule, it
suffices to incorporate them entire by reference.
 
> That's fine by me.  Empty ATTLIST declarations carry no information in
> XML.  (I think that in traditional SGML, they prevent users supplying
> ATTLISTs in the internal subset, but that disappears with WebTC).

I don't think so.  The WebTC, K.4.4.1, explicitly permits empty
ATTLIST declarations, suggesting that they were forbidden before.
(I don't have the text of 8879 available.)
 
> I'm going to push for more than mere comments.  I'd like to see a
> sensible markup for human-readable documentation (Java afficionados
> will know what I mean if I suggest Javadoc, and liken schemas to
> classes, elements to functions and attributes to formal parameters):

Now that is an excellent idea!  However, it would
be necessary to permit arbitrary XML markup within the doco,
so a content model of ANY is probably the right thing here.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan@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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)