XSchema: multiple proposals
cowan at locke.ccil.org
Wed Jun 3 17:25:42 BST 1998
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).
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 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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev