[Bug 3821] Enable element-available() to detect (extension) declarations

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3821





------- Comment #4 from mike@saxonica.com  2006-10-24 11:03 -------
Personal response to your reply:

>>1. Using the system-property() with it will work if all XSLT 2.0 processors and
future XSLT 3.0 processors ... However, if a certain declaration is not
supported in an implementation.

Unfortunately, if processor chooses not to conform to the specification, there
is very little we can choose to do about it. In particular, we can't include
clauses like "if you don't support this element which all conformant processors
are required to support, then you must do XYZ." A vendor who ignores one
conformance rule in the spec is likely to ignore others as well. 

2>> detecting extension declarations ("user-defined data
elements") is still impossible

It's not necessary to detect them, as it is for extension instructions, because
by default a processor will ignore them anyway. 

It's not clear in any case what something like
element-available('saxon:collation') would mean. You can always have a
top-level element called saxon:collation - the element is always available. The
only question is whether the processor attaches any special meaning to it: and
you can determine that by testing  system-property('xsl:vendor').

3>> By the way, ... MSXML 3.0 (with IE6 and IE7), Transformiix (with Firefox
1.5.0.7 and Opera 9 and Xalan-C (tested in Dreamwaver 8) already return true()
to all supported elements. MSXML 4.0+ and libxslt 1.1.15 don't

We're aware that conformance to some aspects of XSLT 1.0 has been patchy, and
we have sometimes taken such evidence into account when deciding how critical
it is to be backwards compatible. I would accept that this is a case where if
we decided that a change was clearly desirable, we would not let backwards
compatibility get in the way.

Received on Tuesday, 24 October 2006 11:03:24 UTC