XSchema: multiple proposals

[Toby Speight]

John> John Cowan <URL:mailto:cowan at locke.ccil.org>


[I've re-ordered this, to put the least contentious (from my POV)
issues first.  Discussion of empty ATTLIST declarations snipped - I
believe you're right.]


=> Toby Speight wrote:

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

=> In article <357569FA.5AD780D5 at locke.ccil.org>, John wrote:

John> So get cracking!  :-)

Point taken.  :-)  Soon, I promise!


>> ... I don't like the way that Choice can be an immediate descendent
>> of Choice, ... - it adds no extra value, and increases the number
>> of ways of representing a particular schema.

John> XML DTDs allow the same flexibility, with content models like
John> "(A | (X | Y))" versus "(A | X | Y)" and similarly for sequences.
John>
John> My proposal states: "It is not possible to reconstruct the exact
John> DTD used to create an XSchema, but a functionally equivalent DTD
John> can be reconstructed."  I think this difference comes under that
John> heading.

Exactly.

John> I agree that having multiple ways of representing the same thing
John> is a Bad Thing.

Looks like we agree here.


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

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

Hmm.  I see your point.  I think what I dislked about Ron's proposal
is the unconstrained #PCDATA here:

Ron> <!ELEMENT NotationValue (#PCDATA)>
Ron> <!ELEMENT EnumerationValue (#PCDATA)>

I think that the list-of-elements structure can be retained, but with
tighter constraints by writing

> <!ELEMENT NotationValue EMPTY>
> <!ATTLIST NotationValue Value NMTOKEN #REQUIRED>
> <!ELEMENT EnumerationValue EMPTY>
> <!ATTLIST EnumerationValue Value NMTOKEN #REQUIRED>

As a bonus, it's slightly less verbose in use (using "/>" syntax).
Perhaps the notation value should be an IDREF to a defined notation?


>> 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):

John> Now that is an excellent idea!  However, it would be necessary
John> to permit arbitrary XML markup within the doco, so a content
John> model of ANY is probably the right thing here.

I'd like to agree at least some conventions here, but I think we
should defer the details until later.  For the moment, I think we
should concentrate on *where* we can put documentation.

With IDREF, we could keep the documentation separated from the schema, but
I'm a follower of the theory which says that the closer the documentation
is to the code, the more likely they are to correspond.


>> 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?  [i.e. how to reference
>> element definitions from other XSchemas?]

John> How about with external parsed entities?  Since we would want to
John> link in whole XSchemas, not just parts of them, as a rule, it
John> suffices to incorporate them entire by reference.

I don't think this is really workable.  We don't have SUBDOC in XML,
nor do we have anywhere in the XSchema DTD that we can insert another
tree rooted at XSchema.  Even if the mechanics can be made to work,
I'm concerned about ID clashes.  Can namespaces help prevent this?

I'm not convinced about wanting only to link-in whole XSchemas, either:
it seems to me that lots of people would want P[aragraph] (and its
children) from HTML, for instance.

-- 


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)