Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema: multiple proposals
 John> John Cowan <URL:mailto:cowan@l...> [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@l...>, 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@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
|
|||||||||
