[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema: multiple proposals
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@c... 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|