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

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





------- Comment #5 from boen.robot@gmail.com  2006-10-24 16:46 -------
>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.
OK. So how exactly does one trigger an instruction workaround for an
unsupported user-defined data element?

> The
>only question is whether the processor attaches any special meaning to it: and
>you can determine that by testing  system-property('xsl:vendor').
Using system-property('xsl:vendor') and/or system-property('xsl:product-name')
is exactly the thing I meant that shouldn't be done for such sorts of
detection. True, some extension might be vendor specific, but others (take
EXSLT for most part) will be available to more then one processor.

If I ,as an author, wanted to make a cross-processor stylesheet that uses
extensions, I would of course want it to be working on all processors, though
partically or slowly in some (is there an unportable cross-processor stylesheet
anyway?). A stylesheet isn't completely portable when it's detecting the vendor
instead of the availability.

An author will have to edit the (hypothetically big) stylesheet every time a
new processor arises, or otherwise, just like JS browser detects, new
processors with support for the declaration might not use it as intended and
will instead get a fallback template, that we could suppose is slower or simply
not working. Or worse. They might execute both the workaround and the
declaration, slowing the process even further or making the output look funny.
Which one of the two of course depends on how the tests were made.

Received on Tuesday, 24 October 2006 16:46:16 UTC