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 ]

Arjun Ray scripsit:

>  <!NOTATION integer PUBLIC "whatever" >
>  <!ATTLIST foo
>            bar  DATA integer  #IMPLIED >
> The full syntax allows the data content notation ('DATA integer') to be
> qualified with data attributes (an attribute specification list within a
> pair of '[' and ']' delimiters).  Note that the DATA keyword automatically
> provides for extensibility in that the notation name ('integer') is "user
> defined" in a separate declaration.

Ah, I hoped to snare an actual SGML weenie into the discussion.
I'm glad this is easy to do.

> http://groups.google.com/groups?selm=ap142t85r6glirbadehjpbq0p0g0936tm4@4ax.com

I will examine this.

> | 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).
> Is this definitional, or a means to specify a list of user defined names?
> I'm not seeing the greater utility of a literal 'LIST(IDREF)' over a plain
> 'IDREFS'.  In the other case, why do we need the 'LIST' prefix when the
> parens provide enough syntactic marking?  

Definitional.  LIST(integer) would mean that the content/value is a
whitespace-separated sequence of integers.  It generalizes the ad hoc -S
ending on the built-in datatypes.  This could be migrated from ATTLIST and
ELEMENT to NOTATION:  we could have something like

<!NOTATION integers #LIST integer>

for example.

> | 8) Restore multiple element and attribute names separated by |s.
> I'd prefer a whitespace-separated list of tokens within parens.  In fact
> I'd like this for all name group and nametoken group usages, instead of an
> infix separator.

What is the precedent here?

> | General issue: Should there be some way to indicate candidate roots?
> | In existing DTDs, any element can be a root.
> Why is this a problem?  I admit I've never understood the issue: is this
> deference to the common fallacy of viewing the FPI of an external subset
> as "declaring a doctype"?  

Remember that we are dealing with external validation here: we don't
want to check whether an incoming document is self-consistent, but rather
whether it's consistent with some schema we already have in hand.  Without
some way to notate the root, an XHTML DTD would accept the document:


The issue is whether this specification should be inside the DTD or
only provided directly to the validator, making it look like "Validate
document X against DTD Y, requiring that the root element be Z."

> Probably irrelevant.  The contents of a document type declaration are
> specific to an instance.  Validation with respect to a fixed set of
> declarations is a separate exercise (as in ArchForms).  The issue would be
> how to declare that fixed set.

That however is what I am discussing here.  In external validation, you
do not want the document to "declare" the set of declarations it is
to be validated against: rather, it is the application that declares it.

John Cowan <jcowan@reutershealth.com>     http://www.reutershealth.com
I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith.  --Galadriel, _LOTR:FOTR_


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

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