Peter Flynn wrote:
Specifying that the *value* of that
attribute must come from a NOTATION-defined space should not implicitly
affect the namespace of the attribute name, only its value. I think
this is what informs current DTD practice, in that
<!ELEMENT code (#PCDATA)>
<!ATTLIST code lang NOTATION (C|Java|FORTRAN) #IMPLIED>
means that <code lang="C">func()</code> says that "lang" *points at*
the C world on this occasion, not that "lang" is *in* the C world. It
also has the implication that the content of the element is in that
world (I don't have my Goldfarb to hand but I think that's the reason
why you can't have more than one NOTATION attribute on an element type,
and why you can't have even one on an EMPTY element type).
This is the correct: the intent of NOTATION attributes in SGML was to
indicate that the notation named governed the interpretation of the
element and its content.
In SGML this provided a simple form of data typing that was orthogonal
to the structural and syntax constraints defined for element
types--there was certainly no requirement, for example, that an element
with a NOTATION attribute contain only text. But very few people
understood this--I think it tended to be easier to just use ad-hoc
mechanisms at the implementation level to bind elements to
semantics--few users required the extra degree of generality that
notations provided. I suspect that is still the case today--if I have an
attribute with the values "c | java | perl | python", as an implementor
I really don't need to dereference "c" to a public identifier that means
"the C programming language" in order to associate the appropriate
processing with that element.
I don't think there's anything in the current XML family of specs that
provides the equivalent semantic of notation, although there might be a
way to do it in XSD (but I'd have to study it--I've not yet internalized
all the details of schemas).
I had from the first days of the development of XML been frustrated by
the apparent difficulty people had with understanding that, as Peter
says, notations are just pointers that give you another way to bind
objects to semantics. But the evidence of this lack of understanding is
the fact that, in XML, notations *cannot* have system identifiers, only
public identifiers, essentially disenfranchising notations from the one
true naming mechanism for Web resources (a naming mechanism later used
for similarly discorporate things, name spaces). But I'm over it now.
The proof of the pudding is in the eating and the XML community has
clearly done just fine without notations, evidence that it was in fact
the correct engineering decision to essentially leave them out (I don't
remember the details of the deliberations, but I'm sure we left them in
for the same reason we left in external parsed entities: there was just
too much legacy that would have balked at XML if they didn't see
notations in the spec, but otherwise the committee had no use for them,
seeing them as another SGML feature that fell outside the 80% line).
If we, as a community, find we need something like notations it will be
trivial to define a namespace/schema pair that defines a single datatype
that means "a URI that is a pointer to an abstract data type that
governs the semantic interpretation of the content of the element on
which the attribute occurs".
But I'm currious to know what system or application actually depends on
notations (of any sort) much less NOTATION attributes--I've not seen or
heard of one in years.
Cheers,
E.
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122
eliot@xxxxxxxxxxxxxxxxxxx
www.innodata-isogen.com