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