OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   John replies to Ron: Differences

[ Lists Home | Date Index | Thread Index ]
  • From: John Cowan <cowan@locke.ccil.org>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • Date: Wed, 03 Jun 1998 11:46:22 -0400

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

> I do not include entities or notations. 

I think that XSchemas must contain all the information that DTDs do
that is visible outside the DTD.  Thus, parameter entities (which
are not visible outside the DTD in XML) can go, but general entities
and notation declarations must remain.  If they do not, XSchemas are
not usable for validation.

(I never meant to imply, BTW, that XSchemas were not useful with WF
documents; on the contrary, a document that is formally only WF
because no DTD is available can be validated by an XSchema validator
if its XSchema is available.)

> To indicate a PCDATA-only element, I use a PCData element while John
> uses an empty MIXED element. Although the PCData element is not
> strictly necessary, I think the commonality of PCDATA-only content
> makes it useful. 

I was thinking that PCDATA-only content is not so common.  Most of
the time, textual elements contain fancy-text information like bold,
italic, or whatever.  Pure plain text with no markup allowed probably
makes the most sense in title elements and such.

See my comments in a previous message on why it's bad to allow both
empty MIXED elements and PCDATA elements in a single design.

> To indicate frequency (optional, required, zero/one or more), I use
> an attribute on Choice, Seq, and ElementRef
> elements while John uses separate elements (OPT, OPTRPT, REPEAT).
> I found John's mixture of frequency and structural information
> confusing. 

I agree that this is better, and will be revising my draft.

> To identify elements and element references, John uses NMTOKEN
> attributes while I use ID/IDREF attributes. John's
> strategy enforces the Name production while mine (possibly --
> I don't know much about IDs and IDREFs) allows use of
> ID mechanisms. 

IDs are better in every way, and I can't imagine why I didn't think
of them.  They impose the same constraints as NMTOKEN attributes,
which is a superset of the Name production, for Names cannot begin
with XML digits.  Changed in the next draft.

> To declare the non-enumerated attribute type, John uses an attribute
> while I used empty elements. I am torn here -- using
> an attribute is much cleaner, but means that enumerated attribute
> types are declared differently than non-enumerated
> types. 

I'm willing to go either way on this one.

> (Note: I couldn't figure out how John declared CDATA and NOTATION
> attributes -- did I miss something?) 

This is what is technically known as a "blunder".  On my part.
Fixed in the next draft.  My intent was to declare notation
attributes like the others, and leave CDATA attributes as the
#IMPLIED value.  But a default of "CDATA" would be better.

> To declare an attribute's default value, John uses an attribute
> and I use PCDATA.

I made a principle of not using PCDATA anywhere except in the
definitions of internal general entities, where it's unavoidable.
(You don't handle entities and so don't have that issue.)
The chief reason is that XML parsers need not expand entities
in PCDATA, leaving the work up to the application, whereas
entities in attribute values get expanded greedily in the parser.

> To declare enumerated values, John uses a CDATA attribute and I
> use PCDATA. We should probably both use NMTOKENS attributes, which
> forces the enumerated values to match the Nmtoken production.

As I said before, I hate NMTOKENS attributes.  I think it is good
to have a sub-element for each enumerated value.  However, I should
not have tried to use the same element for an attribute value default
and for an enumeration value, since one is CDATA and the other is
NMTOKEN (or, actually, Name).  The next draft will fix that.

I note that you require at least one element declaration, whereas
I do not.  A DTD with no element declarations is valid, so I think
I am correct here.

-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS