After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 358309 - element-available() doesn't claim everything it should
element-available() doesn't claim everything it should
Status: RESOLVED NOTABUG
Product: libxslt
Classification: Platform
Component: general
1.1.15
Other Windows
: Normal minor
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-29 13:52 UTC by Vasil Rangelov
Modified: 2006-10-01 08:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vasil Rangelov 2006-09-29 13:52:32 UTC
I recently made something like... um... an XSLT benchmark that tested every XSLT function. Every XSLT processor tested claimed support of most (some even all) XSLT elements.

But for some reason, libxslt doesn't claim support for theese XSLT 1.0 elements:
xsl:attribute-set
xsl:import
xsl:include
xsl:key
xsl:namespace-alias
xsl:output
xsl:preserve-space
xsl:strip-space
xsl:stylesheet
xsl:template
xsl:transform

I haven't verified if that's really true for all of them, but I'm sure that libxslt supports xsl:output, xsl:stylesheet and xsl:template. I mean, if it didn't supported them, it wouldn't have been able to complete the testing process on the first place.

The problem is not the (lack of) support for those elements, but the fact that such isn't claimed when it's present, or in other words:
function-available('xsl:template')
returns false when it should return true instead.
Comment 1 William M. Brack 2006-09-29 16:23:49 UTC
I am a little confused. Reference http://www.w3.org/TR/xslt#function-function-available - can you explain to me why you consider the elements of your above list to be "functions" (as opposed, for example, to "elements")?
Comment 2 Vasil Rangelov 2006-09-30 11:41:25 UTC
Opps. Sorry. The benchmark I made tested elements AND functions. The elements above are the ones that didn't passed element-available() when they should have.

Duh. I'm so stupid... I knew I would mess something up when I report this :D

As for function-available(), I guess it works fine. All XSLT 1.0 functions are supported and a variety of EXSLT ones too.
Comment 3 William M. Brack 2006-09-30 14:21:21 UTC
Ah, ok - now I understand your point.  Unfortunately I believe you have a slight misunderstanding of "element" as used within "element-available".  Referring to http://www.w3.org/TR/xslt#function-element-available,

  "The element-available function returns true if and only if
  the expanded-name is the name of an instruction."

So, one needs to classify which "elements" are "instructions".  For this, refer to http://www.w3.org/TR/xslt#element-syntax-summary.  Here, each "element" is assigned a "Category".  One of these "categories" is "instruction", and it is *only* "instructions" which should produce a "true" result from the function.  I believe you will agree that all of your above-listed elements are not instructions.

I'm glad to see your interest in libxslt's implementation.  A tremendous amount of work was done by the original author, Daniel Veillard, to assure that the implementation was "standards compliant", and I believe he was very successful.  If you find any areas in which the implementation does not meet the standard, please either open an entry here in bugzilla, or send a posting to the mailing list (xslt@gnome.org).
Comment 4 Vasil Rangelov 2006-09-30 16:04:29 UTC
So... top-level elements are not instructions? Weird... then why does every other processor return true? Are they all non-standart compilant about it? I thought that by "instruction" the specification refers to all elements used for XSLT processing (ALL by specification + ALL extensions) o_0.

Oh well, if that is true, I guess it also explains why the EXSLT "func:function" returns false on testing while "func:result" returns true.

Also, just for info... which one of those elements (if any) is truly unsupported and/or what attributes of the supported elements are not? The only one I'm sure of is the media-type attribute of the xsl:output element, but then again... no processor I know of supports it anyway.
Comment 5 Daniel Veillard 2006-09-30 17:09:48 UTC
The other part which is not supported is the support of lang in 
numbering for alphabetical values (section 7.7.1) and using the
environment to influence the transformation. Basically implementing it
would require to link with the ICU library which is 4 time
larger than libxml2 + libxslt for what I consider of little benefit
(still doable if really required but not a default).
Other than that I think XSLT-1.0 support is complete.

Daniel
Comment 6 Vasil Rangelov 2006-09-30 19:34:06 UTC
The test suite which libxslt ran is part of a site deticated to XSLT which I plan to make and (hopefully) soon.

Scince as material I don't have much other than my trivial solutions for trivial problems, I'm interested in this...

Can support for this ICU library be enabled when libxslt is used in PHP (that's how I use it) and how? Please tell. Feel free to mail me too.

P.S. I use PHP on my own Windows server, so you can assume full control of the machine which PHP runs on.
Comment 7 Daniel Veillard 2006-10-01 08:37:36 UTC
No idea how it would be plugged in PHP, there is an example C module
http://cvs.gnome.org/viewcvs/libxslt/examples/
see xsltICUSort.c , the header gives pointers to the discussion and
IBM library.

Daniel