XSchema: multiple proposals

[Toby Speight]

Ron> Ron Bourret <URL:mailto:rbourret at dvs1.informatik.tu-darmstadt.de>

=> In article <199806031121.NAA04198 at berlin.dvs1.tu-darmstadt.de>, 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 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)