Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema: multiple proposals
 Ron> Ron Bourret <URL:mailto:rbourret@d...> => In article <199806031121.NAA04198@b...>, Ron => wrote: Ron> And here [is my XSchema straw-proposal], along with a list of Ron> comments/questions and a list of differences from John's proposal: Ron> Ron> <URL:http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema.html> I have quite a few comments on this proposal; most of them are minor, apart from wanting some provision for documenting schema definitions. The DTD: Ron> <!ENTITY % idref "idref IDREF #REQUIRED"> Most people consider idref or IDREF to be a bad name for an IDREF attribute; each IDREF ought to be named for the role it fulfils. (This is simply a matter of style; it's more important if an element refers to two or more other elements.) Ron> <!ELEMENT Schema (ElementDecl)+> Ron> <!-- id matches the name declared in the DOCTYPE --> Ron> <!ATTLIST Schema %id;> Perhaps I'm confused; I thought that by "name declared in the DOCTYPE" you meant the name of the root element. But if that were the case, you wouldn't be able to use it as the ID (since its ElementDecl would want the same ID). In your XSchema-in-XSchema document, for instance, you never declared the "XSchema" element. I think what you wanted is <!-- root refers to declaration of the root element --> <!ATTLIST Schema RootElement IDREF #REQUIRED> Ron> <!ELEMENT Choice (Choice | Seq | ElementRef)+> Ron> <!ELEMENT Seq (Choice | Seq | ElementRef)+> 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). <Choice><A/><Choice><X/><Y/></Choice></Choice> is equivalent to <Choice><A/><X/><Y/></Choice> and <Seq><A/><Seq><X/><Y/></Seq></Seq> is equivalent to <Seq><A/><X/><Y/></Seq> You also write: Ron> o I do not include entities or notations. Fine by me, at this stage. Ron> o Ron> o To identify elements and element references, John uses Ron> NMTOKEN attributes while I use ID/IDREF attributes. John's Ron> strategy enforces the Name production while mine (possibly Ron> -- I don't know much about IDs and IDREFs) allows use of ID Ron> mechanisms. ID/IDREF values are constrained to be name tokens, but also enforces the uniqueness and existence constraints, so your method is stronger and still consistent with the XML definition. AFAICS, not having studied John's proposal[*], yours won't allow anything his doesn't in this respect. (I note that you had to relax down to NMTOKEN for attribute names, though, which aren't necessarily unique - I don't know an easy way around that). [*] No bias - I was just more rushed when John's appeared. Ron> o Ron> o To declare enumerated values, John uses a CDATA attribute Ron> and I use PCDATA. We should probably both use NMTOKENS Ron> attributes, which forces the enumerated values to match the Ron> Nmtoken production. Do you mean the following? > <!ELEMENT NotationType> > <!ATTLIST NotationType values NMTOKENS #REQUIRED> > <!ELEMENT Enumeration> > <!ATTLIST Enumeration values NMTOKENS #REQUIRED> I like that (more than the current proposal). Your questions: Ron> o Is there any way to ensure that the ElementRef's in Mixed Ron> do not contain any duplicate references? I couldn't think Ron> of any. Nor I. (The same concern applies to Choice, of course). Ron> o ElementDecl's and ElementRef's refer to each other through Ron> ID and IDREF attributes. I have no idea how/if this really Ron> works, but pretty much stole it from XML-Data. Is there a Ron> better way to do this with XLink and XPointer? 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? Ron> o Ron> o I eliminated the AttlistDecl production from the XML spec. Ron> There was no reason to include this because all it did was Ron> name the element to which the attributes belonged and we get Ron> this association through nesting. Note that eliminating Ron> this means that when mapping DTD-> XSchema->DTD, we will Ron> lose any empty attribute lists. Does this matter? 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). Ron> o Ron> o Do we want to include a Comment element in XSchema? There Ron> were some early requests for this, although it didn't make Ron> the final goals. 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): Ron> <XSchema> Ron> <ElementDef> <doc> *purpose of this element* </doc> Ron> <ChoiceOrSeq> Ron> <ElementRef>... <doc> *role of this child element* </doc> Ron> </ElementRef> Ron> ... Ron> </ChoiceOrSeq> Ron> <Attrs> Ron> <AttrDef> <doc> *purpose of this atttribute* </doc> Ron> ...</AttrDef> Ron> <AttrDef>...</AttrDef> Ron> ... Ron> </Attrs> Ron> <OtherStuff> Ron> ... Ron> </OtherStuff> Ron> </ElementDef> Ron> ... Ron> </XSchema> (where the content-model of the "doc" element is yet to be determined). [P.S. Please could you clean up your HTML? I get lots of > Bad start-tag P [not allowed here], inferring <LI> > Containing elements: HTML:BODY:BODYTEXT:UL errors. I don't think that's acceptable for a technical paper.] On the whole, I like this proposal. The only gripe I have is the lack of provision for in-line documentation. Most the issues I've mentioned are minor niggles. Thanks for taking the time to dream this up! -- 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
|
|||||||||
