RE: [xsl] Saxon 8.0b and NOTATIONs

[Peter Flynn <pflynn@xxxxxx>]

On Tue, 2004-07-13 at 11:18, Michael Kay wrote:
> I think you've strayed into an area where the XSLT 2.0 specification itself
> leaves some ambiguities: namely the use of DTD-defined types to set type
> annotations on attribute nodes. You've certainly strayed into wild country
> as far as Saxon is concerned: the schema-aware product has an explicit
> restriction that xs:NOTATION is not a supported data type, but it looks as
> if you can get it in by the back door using a DTD. This is particularly
> troublesome because schema-defined notations are namespace-aware, while
> DTD-defined notations are not. 

>From the user's perspective, the problem is that an attribute on an
element should be in the default namespace of the document unless 
explicitly specified otherwise. 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 what tripped me up: the implication in B8.0 that the attribute
itself was expected to come from the world to which it merely pointed.

> I think the correct behavior is that a non-schema-aware product should
> ignore attribute types defined in the DTD except for the purpose of
> recognizing IDs for use by the id() function (and possible IDREFs for use by
> idref()). However, this isn't very clearly defined in the spec at the
> moment.

I think ignoring the implications of NOTATIONs is probably acceptable,
although (presumably) token list attributes (whether NOTATIONs or not)
would still be restricted to their declared values because the use of
defaults is often critical to processing. ID/IDREF[s} are not the only 
fruit of the attribute world. Having said that, I know of numerous 
applications where the values of the SYSTEM identifier and the FPI have 
to be retrieved when a NOTATION is encountered, because they play a 
role in the referencing systems (eg ISBNs and URIs).

> I'd be grateful if you could send me a package of files that allow me to
> reproduce this error and add a test case.

No problem.

> Incidentally, Saxon bugs should normally be reported on the saxon-help list
> or forum at sourceforge.net. But where it's a question about what the XSLT
> 2.0 spec does or doesn't allow, it's legitimate to use this list - which I
> think covers this case.

I hope so :-) I hadn't even considered that it might be a bug (now
*there's* a tribute to the quality of Saxon!), much more likely that it 
would be my own misunderstanding.

> Actually, I think this is about the first time I have seen anyone using
> NOTATION attributes in anger, with or without a schema.

Forgive me for being slightly shocked at that statement :-) Virtually 
all the commercial (publishing) applications I deal with use NOTATIONs, 
and not just as a fancy substitute for token list strings. They are, 
after all, just another form of pointer, but the advantages of using 
them with FPIs and SIs have been too great for many designers to pass 
up. 

///Peter