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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Come On, DTD, Come On! Thoughts on DSDL Part 9

[ Lists Home | Date Index | Thread Index ]

Norman Walsh wrote:
> / John Cowan <jcowan@reutershealth.com> was heard to say:
> | Example:
> |
> | <!NS foo SYSTEM "http://www.example.com/foo";>
> I've always imagined this as:
>  <!NAMESPACE foo "http://www.example.com/foo";>


By the way, the syntax is:

   <!NAMESPACE prefix name>

A namespace "name" is the URI.

> | Issue: Is it an error to mention a prefix that is not declared?  My
> | answer: no; if this is done, name matching falls back to string identity.
> If the DTD contains an <!NAMESPACE decl, yes, otherwise no.

Also agreed. Don't allow a halfway solution -- you're either using
namespaces or you're not.

> | Issue: is the keyword SYSTEM useful?
> I don't think so. I'm not entirely sure I think it's a good idea to
> use external identifiers for XML namespaces. (I also don't think
> there's a precedent for SYSTEM w/o allowing PUBLIC and, much as I
> support public identifiers, I'm not sure they work sensibly with XML
> namespaces (more's the pity).)

Agreed. The SYSTEM keyword just makes people want to dereference them,
and that's enough of a headache as it is.

> | Issue: this does not help when prefixes are not used consistently
> | throughout an instance.  Do we care?  My answer: no.
> Sure it does. That's the whole point of the declaration!


> | 2) Attribute data types.  The names that can appear in an ATTLIST
> | declaration directly after an attribute name are extended to include
> | the datatype names of part 5 (i.e. XSD simple types).
> |
> | Example:
> |
> | <!ATTLIST baz
> |       foo integer #implied
> |       baz integer #required>
> |
> | Issue: do we need to make the datatype list extensible?  If so, we could
> | use QNames and a DATATYPE declaration, rather like the compact syntax
> | of RELAX NG.
> Mumble. I guess I'd go with qnames and let it be extensible. Off the
> top of my head, anyway.

I like extensibility, but this smacks of interoperability problems. How
does RELAX NG intend that datatype libraries be known?

> | 3) Element simple datatypes.  Likewise, unparenthesized content models
> | in ELEMENT declarations are extended from just ANY and EMPTY to include
> | these same datatypes.
> |
> | Example: <!ELEMENT foo nonNegativeInteger>


> | 4) Datatype lists.  In either #2 or #3 context, a simple datatype name
> | can be replaced by "LIST(name)" to indicate a whitespace-separated
> | list of strings matching the datatype.        IDREFS is equal to LIST(IDREF),
> | and ENTITIES is equal to LIST(ENTITY).
> There's fairly limited utility in extending DTDs. I think this is
> starting to make it too expensive.

Also agreed.

> | 5) Datatype choice.  In either #2 or #3 context, a simple or LIST-wrapped
> | datatype name can be replaced by |-separated names, to indicate a choice
> | (derivation by union in WXS terms).
> |
> | Example: <!ELEMENT bar integer|name>
> |
> | Issue: what do we do about XSD facets?        They are important but don't
> | easily fit into the rigid DTD syntax.
> Too much complexity.

Agreed, both for the feature and the facets. This is clearly not an 80%

> | 6) Restore & connector.  Bring back the & connector, either with the
> | SGML semantics (A,B)|(B,A), or preferably with the RELAX NG "interleave"
> | semantics.  The difference is that, given the content model "A & B+",
> | the element sequences A, B, B, B and B, B, B, A will match in either case,
> | but B, A, B, B will only match using interleave semantics.
> |
> | Issue: SGML or interleave?  My answer: interleave
> My answer, don't do it.

My answer: interleave. This one is requested too often to ignore.

> | 7) Abandon SGML 1-ambiguity rules.  Instead, allow complete flexibility of
> | content models.  See James Clark's discussion in "The Design of RELAX NG".
> Nope.

No opinion.

> | 8) Restore multiple element and attribute names separated by |s.
> | This makes for conciseness and easy authoring.        These constructs were
> | dumped in XML DTDs because they imposed extra cost on validating parsers,
> | but in this model validation is something done outside parsing, so higher
> | cost is worthwhile.
> Nah, I think this is a bit of syntactic sugar I can live without.

Agreed. One of the annoying things about XSD is it has too many ways to
do the same thing.

> | 9) Fixed element content.  Allow ELEMENT declarations to specify "#FIXED
> | 'value'" after a datatype.
> |
> | Example: <!ELEMENT foo integer #FIXED "5">
> |
> | This means that the content of any foo element must be equivalent to 5
> | according to the "integer" datatype's equivalence relation: therefore,
> | 05, 005, +5, etc. will pass validation.
> Nope.

Agreed (as in nope).

> | General issue:        Should there be some way to indicate candidate roots?
> | In existing DTDs, any element can be a root.
> Nope.

Also agreed. If any element can be a root, I can easily reuse DTD/schema
fragments. Stating that a single element (or subset of elements) must be
the root should be tied to a particular application, not the vocabulary
that application happens to use.

-- Ron


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

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