94270 - Implement namespace nodes and namespace axis

Status: ASSIGNED

(Core :: XSLT, enhancement)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Just to get it down into a bug...

We currently don't support the namespace:: axis and thus not namespace nodes

Comment 1

[Jon Kahlo]

I just voted for this bug. I'm trying to access the namespace node with XPath
using the namespace-uri() function.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

one way to reduce memoryuseage when implementing this would be something like this:

1. when requesting the "namespace-list" for an element (A), walk up the tree
   until you find an element (B) with an xmlns attribute. (ugh, that might be
   some hard work right there). If during this walk you find an element with
   a namespace-map, skip to step 3

2. find all namespace-mappings for element B and put them in a map.

3. set a pointer in the elements between the A and B to point to this map.

ok, so now a pile of elements have a namespace-map and we've saved us a bunch of
memory since the map is shared.

The problem is, how do we support walking to the parent of a namespace-node
since many elements share the same map. What you do is that you make the
treewalker (once we have it) not actually leave the element when you step into a
namespacenode, instead it just keeps track of which index in the map it is in,
and which element it is in. Once you need to go to the parent of the node you
just drop the flag that indicates that the walker is on a namespace, and you're
back!

For standalone we could of course create these namespace-maps during parsing,
should be almost free since we won't waste any memory or cycles except when we
hit elements with xmlns-attributes, which if very rare.

Comment 3

[Peter Van der Beken [:peterv]]

Attachment: v1 (WIP)

To do:
-check performance impact on other axes
-createXPathNode(...) for a namespace node
-standalone

Performance is probably not very good, but do we really want to optimize this a
lot?

Comment 4

[Axel Hecht]

Didn't look at the actual namespace axis stuff yet.
But make sure that the DOM part of nsXPathNamespace behaves like other DOM nodes,
i.e. doesn't return null and NS_OK where the other nodes don't (well, at least 
nsGenericElement, IMHO). GetAttributes seems to be a candidate to me.

Comment 5

[Peter Van der Beken [:peterv]]

Ah, right, thanks for reminding me. Add to the To do list:

-implement GetAttributes and CloneNode

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't really care about speed for namespace:: operations (at least not
initially) as long as performance isn't affected for other operations.

Comment 7

[Sébastien CRAMATTE]

I've just voted for this bug. 
I absolutely need namespace:: axis support for my xforms cross browser processor.

Comment 8

[Andrew Thornton]

This is required in order to allow the view xml stylesheet show namespaces
declarations. A patch I sent in to cocoon (cocoon.apache.org) shows how to
adjust the stylesheet to show namespace declarations.

I believe this is important as without namespace declarations it is not
worthwhile viewing XML in Mozilla. (Even IE shows them!)

Comment 9

[William J. Edney]

I'd love to see this in the processor.

I've had to do all sorts of workarounds because of the lack of being able to do 'namespace::' queries both in XSLT's and when invoking Mozilla's XPath processor from JavaScript.

Thanks everyone!

Cheers,

- Bill

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

A cleaner solution then using a bit in the mContent member to indicate attribute vs. namespace might be to use a bit in mIndex. There are plenty of bits to indicate both parent-level and attribute number still.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(if you use the MSB of mIndex you can simply detect if the index is "special" by testing if it's negative)

Comment 12

[bz]

I use this tool (javascript xslt interface):
http://test.datenkueche.com/xml/index.xml
to teach xml.
Without namespace axis there is NO possibility to extend this tool to 
xml with namespaces.

Comment 13

[Lars Huttar]

I just voted for this bug. It is sad that it's sat around for almost 6 years. Looks like Peter had a partial fix in 2004 (comments 3-5) but that's as far as it's gotten. Can I help?

Comment 14

[Lars Huttar]

FYI... I am working on this one now.

Comment 15

[William J. Edney]

Lars -

Thanks for picking this bug up! My knowledge of C++ and the Mozilla codebase is non-existent (even regular C was a long, long time ago).

I wonder if you or anyone else here has run into a bug whereby running an XSLT containing just a simple identity transformation on a piece of XML markup with xmlns="..." attributes *won't even copy these xmlns attributes over to the result markup*. I had to implement a 'heinous hack' in order to make this work.

If there's another bug around this behavior I'm seeing, I'd appreciated someone pointing me to it. Otherwise, I'll open a bug and supply the test case.

Cheers,

- Bill

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That is unrelated to this bug and is arguably bug 76842. But feel free to file a separate bug because what you're describing is an easier subset to fix.

Comment 17

[nico]

Is it really a hard task to implement the namespace axis in the XSLT processor ? I really need that feature in order to generically transform a schema into a web form and keep the prefix declared in the schemas.
Otherwise you could just allow the access to xmlns attributes of the root markup, that's all I need !

Comment 18

[Alain COUTHURES]

It is frustating to discover that the FireFox XSLT Processor still doesn't support this standard point.

I need this feature to convert XForms to XHTML+Javascript with XSLT

Comment 19

[wcmpt212]

I am part of a 3 person team interested in helping with Mozilla's implementation of the namespace axis in XSLT processing.  For clarification of the problem I would like to know the answer to the following question.  

Where is it that xmlns attributes are being ignored?  Is it the fact that xmlns attributes are extracted during parsing and are subsequently being ignored in the production of the document tree, or is the problem lower down in the expat parsing process itself.  

I too have noticed, similar to comment #15, that namespace attributes do not appear in the document tree displayed after an XML file is attempted to be opened in the Mozilla Browser when, for example, the accompanying stylesheet is missing.  

I'm just getting into the code, but I've noticed in the proposed patch attached to this bug that the idea was to walk the tree to extract namespace node information, which would imply that the information was in the tree; but if so, why doesn't it appear in the displayed document tree.

Comment 20

[Mark Strange]

I am part of the aforementioned 3 person team of students, and have a few other comments to make on the matter:

The original attachment made by Peter Van der Beken, with suggested changes, may not be a valid set of changes anymore. The TransforMiiX module used by Mozilla for XSLT and XPath is no longer a discrete directory in the mozilla source code structure. The functionality is still there, and we have located a great deal of the corresponding files in /content/xslt/src/xpath/, but not all the files suggested for changes are present in this directory. Whether this indicates that the module has undergone significant restructuring, or we have just not been able to locate the rest of the module's files is unknown at this point.

We have been able to show that the bug still persists in Firefox, but with our limited knowledge of how the code works, it may be some time before we can wrap our heads around finding a solution. We are in the process of finding a way to test the proposed changes by Peter Van der Beken, but with the TransforMiiX module in a different state now, this may take some time as well.

Comment 21

[Lars Huttar]

I don't have much to add, but I can just say that when I started trying to work on this code a couple of years ago, it was in a similar state to what you just described. I'm glad to see someone working on this; I have not been able to continue working on it, but would still be very happy to see it done.

The first file in Van der Beken's patch, build/XSLTProcessorModule.cpp, now seems to belong in extensions/xmlextras/build/src/nsXMLExtrasModule.cpp... or that was my conclusion two years ago.

I will attach two files: my notes on the whole issue (Mozilla Bug 94270 Notes.doc), and a my start on a patch (my_94270-begun.patch). I'm not sure how far the latter got. If there is anything else I can do to help I would be happy to do so. Best of luck.

Comment 22

[Lars Huttar]

Attachment: Beginning of a patch, by Lars

This is not a complete patch.

Comment 23

[Lars Huttar]

Attachment: Misc. notes on how to fix the bug.

Comment 24

[Lars Huttar]

See also bug 373438.

Comment 25

[Peter Van der Beken [:peterv]]

Attachment: v2 (WIP)

Here's a patch that applies to current trunk. It's only lightly tested.

Comment 26

[Lars Huttar]

Woohoo!!

Comment 27

[William J. Edney]

Might I suggest that the 3 person team that was hot to get this fixed (and graciously offered to do so themselves) write some tests to really beat on this patch?

That would give Peter a target to shoot for in moving this patch from 'lightly tested' to 'fully tested' and checked in for Moz 1.9.2 (wink, wink ;-) )

Everyone involved here has my thanks in moving this long-standing bug to a state of 'FIXE' :-).

Cheers,

- Bill

Comment 28

[C. M. Sperberg-McQueen]

To answer, indirectly, the question in comment #19: the problem,
as far as I know, is not that namespace attributes are ever
completely ignored in the parsing of the XML data stream.  (If
they are, that would surprise me.)  The problem is that the
interface to the document tree does not expose namespace
information in the form of namespace nodes (as described in the
XPath data model), which means that when XPath expressions use
the namespace axis, they find no nodes.

One concrete example may help; it is what led me to this bug in
the first place, a few months ago.  In the stylesheet at
http://www.w3.org/2008/09/xsd.xsl -- it displays XSD schema
documents in a browser- and reader-friendly form -- there is code
to display various QName references, and to hyperlink them to the
appropriate targets if appropriate.  To tell whether the QName
refers to a component declared in the current document, the
stylesheet needs to know the expanded name (URI + NCName pair) to
which the QName maps.  It does so, for most XSLT processors, by
asking for the value of the namespace node whose name() is the
prefix in question:

  <xsl:value-of select="string(namespace::*[name()=$prefix])"/>

This is, perhaps, a reasonable illustration of the problem in the
current Mozilla code: for Mozilla, the expression 'namespace::*'
always returns the empty nodeset, which means that I end up with
the empty string as the namespace name (which is one value that a
namespace name can never have).  

The workaround is the following code in another place in the
stylesheet.

    <xsl:when test="count(ancestor::*/namespace::*) = 0">
     <!--* we are either in a no-namespace document in Opera,
         * or we are in Firefox, without ns support.
         *-->
     <xsl:value-of select="'no-ns-support'"/>
    </xsl:when>

I hope this helps elucidate the nature of the problem and what at
least some of Mozilla's users are looking for out of a fix to
this bug.  When Mozilla can display the schema document
http://www.w3.org/2008/09/sml-schema.xsd and the user can see,
in the description of "Complex type keybase", that in the lines

    <xs:element name="selector" type="sml:selectorXPathType"/>
    <xs:element name="field" type="sml:fieldXPathType" maxOccurs="unbounded"/>

the QNames sml:selectorXPathType and sml:fieldXPathType are
hyperlinked to anchors elsewhere in the document, then this bug
will have been fixed, at least partially.

If this example helps achieve the goal set in comment 27, all the 
better.

Comment 29

[Lars Huttar]

Wow, a comment from C.M. Sperberg-McQueen... this bug has hit the big time!

And since he has Erdős number 6, does that mean all the rest of us who also commented on this bug have Erdős number 7?

Comment 30

[wcmpt212]

Attachment: V2.1 (WIP) - Fix to correct duplicate namespace handling

Created patch V2.1(WIP) 

In order to contribute something as an interim result of our limited testing to date, we have created the above fix to patch V2 (WIP); and so labelled it V2.1 (WIP), reflecting its very small one line change.

While testing patch V2 (WIP) on the current trunk, we noticed that duplicate namespaces were not handled correctly, and traced the problem to the way that the already declared namespaces were being stored within the prefixes array. 

Specifically within txXPathTreeWalker::moveToValidXMLNSAttribute() our fix makes the following one line change:

V2 (WIP) patch

	prefixes.InsertElementAt(attrName->GetPrefix(), xmlnsIndex);

V2.1 (WIP) fix

	prefixes.InsertElementAt(attrName->LocalName(), xmlnsIndex);

The problem was that by using GetPrefix() the code was storing the prefix "xmlns" of the xml element "<xmlns:prefix>", whereas  by using LocalName() "prefix" is correctly stored instead.

This fix brings the patch in line with the W3C standard, XML Path Language (XPath) Version 1.0, section 5.4 Namespace Nodes. Specifically, an element will have a namespace node: 
	... for every attribute on an ancestor element whose name starts
 	xmlns: unless the element itself or a nearer ancestor redeclares the 		prefix; ... .

Our simple xml test case and accompanying style sheet attached with this fix (test13.xml and test13.xsl) preforms such a redeclaration.

Comment 31

[wcmpt212]

Attachment: Test Case for V2.1 (WIP) patch

Test Case - Test13.xml regarding comment #30 above

Comment 32

[wcmpt212]

Attachment: Test Case Style Sheet for V2.1 (WIP) patch

Test Case Style Sheet - Test13.xsl regarding comment #30 above

Comment 33

[Rob Cameron]

Hi.   I'm the prof of the CMPT212 course that has the 3-student team
tackling this bug.   The students have been able to apply the
patch provided by Peter Van der Beken, test it and make a small
change to correct a bug with respect to duplicate namespaces.

For the remaining few weeks of the course project, I've asked the
students to further develop both white-box and black-box based test cases,
as well as analyze the code.    Any additional test case contributions
by others would of course be welcome.

Presuming that Peter's patch is on the right track, which it appears
to be, what else needs to be done to get this change checked in?

Comment 34

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The only other thing that would concern me is performance for stylesheets that do not use the namespace axis. So some basic performance testing would be great.

Peterv: I know you had some tests in the past. Are they still around somewhere?

Comment 35

[Tyler_cmpt212_tsa45]

I am CMPT212 student having project on this bug. right now we are testing the patch. a part of white box testing is to add print statement on each importent branches for testing. but the output could be a problem because it is difficult to know exactly which branch is not gone through. so we plan to make a simple C++ helper class, which contains 2 main static methods. one will be put in   
every branches we want to test, passing in the name of this branch and add into a result file. after testing, second method will be used to load the result file, and compare with ALL branches names with ones in the result file, then print the names of those branches which are not gone through. 

right now it is just a plan and we hope this will makes sence

Comment 36

[Mark Strange]

Attachment: Performance Testing of WIP Patch v. 2.1

A thousand apologies. I should have posted this weeks ago when I finished it.
This is the result of our computing science course project's performance testing.
The performance testing consisted of measuring the total number of CPU cycles to do a certain process. Two cases were considered: the time needed to build the namespace nodeset, and the time needed to parse each node in the document.
In the .ods file, there is the raw data in separate sheets, and a binary order of magnitude profiling of each test.
The two of most interest are at the end of the first sheet, the Patched version of firefox testing the parsing time, both with a namespace document and a non-namespace document. The test of nodeset building was not invoked when a non-namespace document was loaded, so the results of that test are not included.

Hopefully all that made sense, but the gist of it is that with the patch (post to follow) there is no adverse affect on performance when a non-namespace document is opened.

Comment 37

[Mark Strange]

Attachment: WIP Patch version 2.1 (updated)

Final version of the patch we produced in the progress of our comp sci course project.

Comment 38

[William J. Edney]

Mark, thanks for posting this. Thanks to the CMPT212 team for pushing this along.

So where does that leave us on this long-standing bug? Do these performance numbers look good enough for the 'powers that be' here? (you know who you are ;-) )

If so, can we get approval, r, sr, etc. for a checkin for the next version of Mozilla?

Thanks to all involved here!

Cheers,

- Bill

Comment 39

[Ken Herdy]

Attachment: XSLT based testsuite used to verify the namespace axis support provided by the '94270_1.patch' patch file.

This gzipped tarball contains an XML test data file, XSLT test suite file, ReadMe file and the '94270_1.patch' patch file used in the development of the this test suite.

Comment 40

[Ken Herdy]

I have completed a review of this namespace axis support feature request and created an XSLT based test suite to verify the 94270_1.patch patch file.

My basic approach was to use the Oxygen 10 XML editor together with the Namespace 1.0 and XPath 1.0 specifications to develop a set of expected results for comparison against the actual results returned by a patched (94270_1.patch) Firefox trunk build. The Oxygen editor uses Saxon-SA, LIBXML or Intel XSS as the underlying XPath/XSLT engine. For the most part I used the Saxon-SA XSLT engine to verify results and XPath expressions.

I worked through Comment #28 From  C. M. Sperberg-McQueen. The patched version of Firefox works correctly for this case.

In applying the patch, 3 hunks were rejected for txMozillaXPathTreeWalker.cpp and 2 files had moved.

I manually applied the rejected hunks and pointed to the following files.

dom/public/nsDOMClassInfoID.h -> dom/base/nsDOMClassInfoID.h
dom/src/base/nsDOMClassInfo.cpp -> dom/base/nsDOMClassInfo.cpp

Attached above is gzipped tarball of the test suite files as well as the patch file. The data file contains the test case data and excepted values. The XSLT stylesheet contains the XPath expressions and assertion logic.

All tests pass with the exception of test 20. Tests 4,5,8 and 9 do not rely on the namespace axis and perform correctly in both the patched and unpatched versions of Firefox. Test 20 returns the namespace node count value of 8. Saxon-SA, LIBXML, and Intel XSS return a namespace node value of 3. This is mostly likely not a bug with the namespace axis but rather with the count() function in Firefox.

Comment 41

[Ken Herdy]

Attachment: WIP Patch V2.2 (updated)

Created new patch file with updated file paths.

Comment 42

[Peter Van der Beken [:peterv]]

Comment on attachment 376776 [details] [diff] [review]
 WIP Patch V2.2 (updated) 

This should be reviewed by sicking, but I want to take a look first since I wrote the original patch.

Comment 43

[Mike Shaver (:shaver emeritus)]

Can someone sketch the use cases for this?  Just trying to get a sense of what motivates the work -- do other browsers support this? Does it make something interesting possible?

Comment 44

[C. M. Sperberg-McQueen]

[Responding to comment 43]

The primary use case for the namespace axis (at least, the one I'm most aware of) is for processing QNames when they appear in data (i.e. element content or attribute values), as opposed to being used as the generic identifier of an element or as the name of an attribute.  QNames are used in data by a number of languages intended for the definition of XML vocabularies or the processing of XML instances; examples which may be familiar include the use of QNames in:

  - XPath expressions (as used in XSLT stylesheets in 'select' and 'match' attributes, in Schematron schema documents in 'assert' and 'report' elements, in XSD 1.1 assertions, in the description of the model-view connections in XForms documents, internally or as part of the user interface in some search interfaces, and no doubt also in other contexts)
  - lists of element types (as, for example, in the 'elements' attributes of the xsl:strip-space and xsl:preserve-space elements)
  - references to XSD schema components (type definitions, element declarations, etc.) in XSD schema documents and in the xsi:type attribute, which can appear in document instances being validated

Obviously it's essential for implementations of languages like XSL or Schematron or XForms or XSD to be able to inspect the set of in-scope namespace declarations; comment 7 illustrates this requirement.  It can also be important for code that uses both XSLT and other technologies (e.g. Javascript), as illustrated by comment 9 and comment 12.  Comment 17 and comment 18 may be in this class, too.

But it's not just implementations of XSLT, XForms, etc., that need to understand QNames in data:  ancillary tools which process XSLT stylesheets, XForms documents, or Schematron or RelaxNG or XSD schema documents as document instances often also need to have access to the namespace axis, even for the simple task of making an informative display of the document; see comment 8, comment 15, and comment 28.

I hope this illustrates at least some of the use cases for the namespace axis.  Part of the motivation for the work is just that the namespace axis is part of the XSLT spec; supporting it will improve the standards compliance of the implementation.  But beyond that, it does definitely make some interesting things possible.  

As far as I know, every other browser in which I've tested XSLT (IE, Opera, Safari) supports the namespace axis.   HTH.

Comment 45

[William J. Edney]

Mike -

I would just add from my more pedestrian viewpoint :-), that not having 'namespace::' axis support in Transformiix has been maddening for those of us trying to use or author tools such as Dimitre Novatchev's XPath Visualizer. He eventually found a sub-optimal workaround, but it was painful and incomplete.

And, yes, all other browsers that support XSLT have supported the 'namespace::' axis since the beginning. This is because IE uses MSXML and Webkit uses libxslt, both libraries that have seen lots of usage outside of those respective products.

Another comment I'll make here, and I'm not trying to be snarky. I'm sure that writing Transformiix seemed like a good idea at the time. That was a long time ago, however, and times have changed. The XSLT API to us JSers, anyway, has a very small surface - not sure about how many C coders are using C-level API. This bug report isn't the place to debate moving to something like libxslt, but since most of the Mozilla 'powers that be' around XSLT are subscribed here, maybe its something that should be debated there at Mozilla. I'd be willing to participate in that discussion.

Cheers,

- Bill

Comment 46

[Mike Shaver (:shaver emeritus)]

IIRC, we didn't write Transformiix, we adopted it from an existing project.  An experiment to replace our XSLT library with libxslt would be welcomed by me -- good data on speed/space performance, better understanding of the contact points -- but belongs in another bug.  (An experiment to write XSLT in JS would be even more welcome, I must confess. :) )

Comment 47

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd be all for someone trying to integrate libxslt. The problem last I looked was that libxslt could not operate on our data structures directly, but instead had to operate on its own internal objects. So in order to use libxslt we for each interaction have to copy the whole DOM tree into an libxslt DOM, then perform the XSLT/XPath operation. This is extremely expensive for things like small XPath operations.

The one exception is transformations done using the <?xml-stylesheet?> processing instruction, where we could create a libxslt DOM right away, and never create a gecko DOM.

If libxslt has changed such that this is no longer the case then it could very well be very interesting to look at. I'm all for someone giving it a try and if performance and other metrics look good it'd be nice to use an off-the-shelf XSLT engine rather than having to use our own.


That said, if namespace:: support is the only thing missing. There is a patch attached to this bug. I have not yet looked at what state it is in, but I'd imagine that it'd be less work to integrate it, rather than integrating all of libxslt.

Comment 48

[Ken Herdy]

See Comment #40 and the attached XSLT Test Suite as a way to verify the namespace:: axis support for at least the <?xml-stylesheet?> processing instruction based use case.

Comment 49

[Peter Van der Beken [:peterv]]

(In reply to comment #40)
> All tests pass with the exception of test 20. Tests 4,5,8 and 9 do not rely on
> the namespace axis and perform correctly in both the patched and unpatched
> versions of Firefox. Test 20 returns the namespace node count value of 8.
> Saxon-SA, LIBXML, and Intel XSS return a namespace node value of 3. This is
> mostly likely not a bug with the namespace axis but rather with the count()
> function in Firefox.

Actually, test 20 looks wrong. The XSLT rec clearly states that namespace nodes are not shared between elements. |nsa:data/descendant-or-self::*| returns |<nsa:data><x xmlns:edi="..."><y/></x></nsa:data>|, nsa:data has 2 namespace nodes (nsa and xml), x has 3 (edi, nsa and xml) and y has 3 (edi, nsa and xml) and 2+3+3=8. LibXML also returns 8 for me (both run in Safari and standalone with xsltproc).

Comment 50

[C. M. Sperberg-McQueen]

At first glance, I believe Peter Van der Beken is correct in saying test 20 should expect 8 not 3 as its result.  Like him, I have run the tests with Safari and with xsltproc and both produce the result 8, as do Opera 9.63, Saxon 6.5.3, Saxon 9.1.01, and Saxon SA 9.1.0.5.  I'm not quite sure why PVdB and I are getting results different from those reported by Ken Herdy in comment 40. But I'm tolerably confident the test formulation is not quite right. 

This discrepancy led me to wonder whether the expected results for the other tests are correct, too; I have not examined them manually but for what it's worth I should mention that for the other tests, the expected results are what all the other processors I tested are producing, so they have at least that degree of plausibility.  I thank Ken Herdy for making the tests so easy to run.

Comment 51

[Ken Herdy]

Not to muddy the water, but it is interesting to see that test 20 returns a node count of 3 for XPath 1.0 and a node count of 8 for XPath 2.0 with LibXML, Saxon SA, Intel XSS. I believe Firefox XSLT conforms to XSLT 1.0/ XPath 1.0.

Comment 52

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The XPath1.0 spec clearly says:

"Elements never share namespace nodes"

http://www.w3.org/TR/xpath#namespace-nodes

I also strongly doubt that the problem is in the implementation of count() since all it does is return the length of the nodeset. So there's probably too few nodes in the nodeset rather.

Comment 53

[Ken Herdy]

My mistake, Saxon-B 9 returns a namespace node count of 8 for test 20. Xalan, used by the Oxygen 9 XML editor returns a node count of 3 for test 20.

Comment 55

[nico]

Is it possible to commit that fix ?
People from xml-dev list agree that the value returned for test 20 must be 8. See answer there :
http://markmail.org/search/?q=support+XML+browser&q=list%3Aorg.xml.lists.xml-dev#query:support%20XML%20browser%20list%3Aorg.xml.lists.xml-dev+page:1+mid:rv7zuu2cv5m6qhqw+state:results
So it is ok, thanks for that work !

Comment 56

[Nochum Sossonko [:Natch]]

The patches here are all WIPs so far and are not unified diffs...

Comment 57

[Jorge L. Williams]

I'm confused about the status of this?  Can we expect the Namoroka release to finally have support for namespace nodes and the namespace axis?  Or is this a ways off?

Thanks

Comment 58

[William J. Edney]

I'll chime in here as well and ask what the status is.

It looks like we have an attached patch, but there may be some difference of opinion of return values of one of the tests.

I'm willing to help to get whatever issues that are left to get this patch to 'r', 'sr' and 'committed', but I don't really know where we're at. I'm not a C developer, but I do use the XSLT processor from the JS API extensively and can test stuff.

Any of the Mozillians care to chime in here?

Peter... Jonas... Mike... Axel... Bueller... Bueller... :-)

Cheers,

- Bill

Comment 59

[Benjamin Smedberg]

The status is that this bug is very low priority compared with other efforts and is likely to sit here unless somebody else takes ownership, requests reviews with proper tests, etc.

Comment 60

[Dan McCreary]

First of all, thanks to everyone that is making XML and XSLT support in FireFox better.  This is a critical issue and has allows us to attempt to get XForms running in the client on the Mac.

I would like to vote to have this priority raised.  We are using an implementation of XSLTForms and we have found that it works very well on all browsers except FireFox due to this issue.

I have documented the issue and workaround here:

http://en.wikibooks.org/wiki/XRX/XSLTForms_and_eXist#Problem_with_Namespaces_in_FireFox_Browser

We will be waiting any new developments on this issue and I will volunteer to help test the fix.

Thanks! - Dan McCreary

Comment 61

[Adam Retter]

I would just like to add my support to Dan McCreary's comments and emphasize that this is an important fix for both XForms and XSLT support.

Adam - eXist dev

Comment 62

[Mukul Gandhi]

(In reply to comment #0)
> Just to get it down into a bug...
> 
> We currently don't support the namespace:: axis and thus not namespace nodes

I was reading C. M. Sperberg-McQueen's blog post (ref, http://cmsmcq.com/mib/?p=757), where it's suggested that, the XSLT namespace axis must be provided into Mozilla product available to the community.
I agree to this. here's my +1 vote for this.

Regards,
Mukul

Comment 63

[Fabrice Desré]

What would be helpful would be to ask for review. It won't get landed without this.

Comment 64

[Peter Van der Beken [:peterv]]

I think we need to split off namespace nodes from the namespace axis, exposing namespace nodes in the DOM is more complicated than what's currently in the patch and will take more work. I think the namespace axis work is reviewable though, so let's move that forward. We'll need automated tests, so ideally someone would convert at least the tests in attachment 376122 [details] into an automated test. I discovered a bug in the following:: axis with a namespace node as the context node, so the tests are clearly incomplete.

As an aside to comment 45 and 46, afaik WebKit has its own XPath implementation too, separate from libxslt (with XPath namespace nodes).

Comment 65

[Peter Van der Beken [:peterv]]

Attachment: v2.3

This implements just the namespace axis, not the DOM namespace nodes.

Comment 66

[Peter Van der Beken [:peterv]]

Attachment: v2.3

Bleh, qrefreshed into the wrong patch.

Comment 67

[Peter Van der Beken [:peterv]]

Attachment: v2.3

Comment 68

[Mukul Gandhi]

(In reply to comment #63)
> What would be helpful would be to ask for review. It won't get landed without
> this.

I am not sure, if I can review the source code for this. It's been a while, I have worked with C++.
But I am keen to test this functionality, as it get's available in the final Mozilla product, or perhaps as a preview, which might work in Mozilla browser environment.

Regards,
Mukul

Comment 69

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 408003 [details] [diff] [review]
v2.3

I do wonder if it'd be worth letting moveToFirstNamespaceNode() and moveToNextNamespaceNode() take an array argument to avoid the current horrible performance for the namespace axies. Which the caller must pass in for each call. Up to you.

>+PRBool
>+txXPathTreeWalker::moveToValidXMLNSAttribute(PRUint32 aAncestorIndex,
>+                                             PRUint32 aAttributeIndex)
>+{
>+    // XXX If this is ever on a critical path (ugh!) we should cache mPrefixes
>+    //     between calls.
>+    nsVoidArray prefixes;
>+
>+    PRUint32 ancestorIndex = 0;
>+    PRUint32 xmlnsIndex = 0;
>+
>+    nsIContent* parentElement = mPosition.Content();
>+    nsIContent* ancestorElement = parentElement;
>+    do {
>+        PRUint32 total = ancestorElement->GetAttrCount();
>+        PRUint32 attributeIndex;
>+        for (attributeIndex = 0; attributeIndex < total; ++attributeIndex) {
>+            const nsAttrName* attrName =
>+                ancestorElement->GetAttrNameAt(attributeIndex);
>+            if (attrName->NamespaceID() != kNameSpaceID_XMLNS) {
>+                continue;
>+            }
>+
>+            nsIAtom* name = attrName->LocalName();
>+
>+            PRBool valid;
>+            if (name == txXMLAtoms::xmlns) {
>+                // Check if it's "undeclaring" the default namespace.
>+                nsAutoString value;
>+                ancestorElement->GetAttr(kNameSpaceID_XMLNS, txXMLAtoms::xmlns,
>+                                         value);
>+                valid = !value.IsEmpty();

Do you need to remember if this returns false, so that if you find a default namespace declaration later you ignore it?

Also, the errata refers to the fact that in XML Namespaces 1.1 prefixes can also be undeclared. And since we use XML Namespaces 1.1 for our xml parsing (I believe?) I suspect we wanna support that here too.

>@@ -399,10 +504,33 @@ txXPathNodeUtils::getLocalName(const txX
...
>+    const nsAttrName* attrName = element->GetAttrNameAt(attributeIndex);
>+    nsIAtom* localName = attrName->LocalName();
>+    if (attrName->NamespaceID() == kNameSpaceID_XMLNS &&
>+        localName == txXMLAtoms::xmlns) {

Nit: Might be slightly faster to switch the order here, since the second test should be faster and should almost always fail.

>@@ -419,9 +547,27 @@ txXPathNodeUtils::getPrefix(const txXPat
>         // which is what we want here.
>         return aNode.Content()->NodeInfo()->GetPrefixAtom();
>     }
> 
>-    return aNode.Content()->GetAttrNameAt(aNode.mIndex)->GetPrefix();
>+    nsIContent* element = aNode.Content();
>+    PRUint32 attributeIndex;
>+    if (aNode.isNamespaceNode()) {
>+        if (aNode.isXMLNamespace()) {
>+            return txXMLAtoms::xml;
>+        }
>+
>+        PRInt32 ancestorIndex = aNode.GetAncestorIndex();
>+        while (--ancestorIndex >= 0) {
>+            element = element->GetParent();
>+        }
>+
>+        attributeIndex = aNode.GetAttributeIndex();
>+    }
>+    else {
>+        attributeIndex = aNode.mIndex;
>+    }
>+
>+    return element->GetAttrNameAt(attributeIndex)->GetPrefix();

Actually, the spec doesn't say what the prefix should be for namespace nodes. I would almost argue that it should be null since nothing is mentioned.

In any case it seems wrong that the xml namespace node has prefix "xml", the default has prefix "" and all other has prefix "xmlns".

r- based on undeclaring namespaces stuff. Looks good otherwise.

Comment 70

[Kostis Anagnostopoulos]

Please, commit the fix as it is *now*, 
since many people have worked for months to fix it
and it is disrespectfull to them to leave it floating around for so many months!

Since it does not affect the rendering of html pages or the performance of FF,
commit this fix now and let the xml-developers fix report any problems later.

Comment 71

[Grégoire Colbert]

Will this be fixed in Firefox 4?

Comment 72

[Dan McCreary]

Does anyone have any status updates they can share?  I will offer to buy a FireFox T-shirt to anyone that can get this fixed! :-)

Comment 73

[Michael Kay]

Concerning the disputed test 20. My analysis is that there are three elements selected (nsa:data, x, and y). The nsa and xml namespaces are present on all three elements. The edi namespace is present only on x and y. So there are 8 namespace nodes in all. The answer 3 is clearly wrong.

Now, I'm a great believer in trying to achieve 100% conformance to specs. Pragmatically, however, conformance is more important in some areas than others. Many, many stylesheets use the namespace axis to discover the in-scope namespaces of a particular element. Very, very few care about the identity or parentage of namespace nodes. So please don't use this test as a reason to hold up the feature which so many people need, and which is now ten years overdue as the history of this bug demonstrates.

Comment 74

[S Silcot]

As a humble web developer trying to apply XRX techniques I would like to first thank all those at Firefox/Mozilla whom have worked so hard to get this fixed and second, respectfully, lend my strong support to the requests of Messrs Kay, McCreary, Retter and the many many others above who have pointed out the importance of getting this xml namespace handling bug fixed in Firefox. 

Is the fix mentioned by Mr Anagnostopoulos (#70, April 2011, nearly 11 months ago) going to be committed? 

Could the assignee of this bug be so kind as to provide a status update. This would be very much appreciated, thankyou.

Comment 75

[Conal Tuohy]

As an XSLT developer I would like to see this patch committed, too. It's a shame that Mozilla is actually lagging other browsers in compliance with the spec.

It seems to me that a patch is ready to be committed, but for some reason the commit hasn't happened - is there more that has to happen? Some testing? 
Is there anything I can do? 

Can someone in the know comment on where the process goes from here?

Thanks!

Comment 76

[Emmanuel]

As a small company using XSLT and XForms for its business needs, the namespace axis is essential to us. We have to revert to workarounds because of this bug. It seems providing a status update or, even better, committing this feature would greatly benefit the community of users. Many thanks in advance.

Comment 77

[Peter Van der Beken [:peterv]]

The patch has been reviewed, it needs changes. I probably won't be able to land this soon. Beyond that there's not much else I can say, and it'd be nice if people would stop adding more comments that do not directly discuss the patch. Thanks!

Comment 78

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 53 votes.
:peterv, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.