[
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:
<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@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_
|
