Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Come On, DTD, Come On! Thoughts on DSDL Part 9
 Norman Walsh wrote: > > / John Cowan <jcowan@r...> 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"> Agreed. 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! Agreed. > | 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> OK. > | 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% case. > | 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 
|
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
|
|||||||||
