Re: [xsl] Saxon 8.0b and NOTATIONs

Subject: Re: [xsl] Saxon 8.0b and NOTATIONs
From: Eliot Kimber <ekimber@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 14 Jul 2004 19:07:25 -0600
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)>

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.


W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122


Current Thread