[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

John replies to Ron: Queries

• From: John Cowan <cowan@l...>
• To: XML Dev <xml-dev@i...>
• Date: Wed, 03 Jun 1998 10:47:41 -0400

Ron Bourret writes at
http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/issues.html :

> Issues:
> 
> ElementDecl deviates from elementType in XML-Data. elementType does
> not require any members of the first group (the content model
> declaration); presumably, a missing content model means empty.
> ElementDecl follows the XML spec, which requires a content model.

I think, rather, that XML-Data is trying to handle more general
data sources than XML documents, for some of which the whole
concept of a content model may make no sense.  What is the content
model of a Java object?  It has a name and attributes, but nothing
reasonably adhering to the concept "content model".

This is not a goal for XSchema 1.0, so I agree that your choice is
correct.

> ElementDecl contains ElementRef and PCData for simplicity. These are
> common content models and, although they could be placed in Seq/Choice
> or Mixed, respectively, the efficiency in including them seemed to be
> worth the deviation from the XML spec. This follows the model used by
> XML-Data. 

I agree wrt ElementRef. See below for comments on Mixed.
 
> It is possible to replace Choice and Seq with a Group element,
> which would have an attribute specifying whether the
> Group is a Choice or a Seq. This is what XML-Data does. I chose to
> follow the XML spec.

Again, XML-Data is trying to be general.  Note that it can handle
SGML &-groups, and potentially other kinds of groups (XOR-groups?)
too.
 
> Mixed is declared as containing zero or more (*) ElementRef's.
> This matches the XML spec but not the XML-Data spec,
> which says it must contain one or more (+) ElementRef's.

I think that either you should require Mixed to have one or more
children, or else you should eliminate the separate PCData element.
Otherwise, the choice is arbitrary between an empty Mixed element
(which is what my proposal uses) and a PCData element.  Arbitrary
choices are bad.  (IMHO it is better to have just Mixed, particularly
since #PCDATA-only content is still called "mixed content" in
SGML-ese.)

> Questions:
> ElementDecl's and ElementRef's refer to each other through ID and
> IDREF attributes. I have no idea how/if this really
> works, but pretty much stole it from XML-Data. Is there a better way
> to do this with XLink and XPointer?

No, I think that ID and IDREF win here.  XLink is overpowered for
the purpose, and since all references are internal, the XPointer
would just be "#the-id" instead of "the-id".  Why add an extra byte
when ID/IDREF do it correctly?
 
> Is there any way to ensure that the #PCDATA in EnumerationValue,
> NotationValue, and AttValue match the correct XML productions?
> I can't think of any.

I don't think so, which is one reason that I avoid #PCDATA in
elements.

> Do we want to include a Comment element in XSchema? There were some
> early requests for this, although it didn't make the final goals.

What for?  Comments are comments, and XML comments work fine in
XSchemas.  We don't want to resurrect the dreaded COMMENT element
from Netscape HTML, or was it Microsoft HTML.

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

• Prev by Date: Re: XSchema: multiple proposals
• Next by Date: Re: Namespaces and Parsers
• Previous by thread: LISTADMIN: Daily digests instead of weekly ones?
• Next by thread: John replies to Ron: Differences
• Index(es):
  • Date
  • Thread