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@[...].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:

<p> foo</p>

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@[...].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_

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>