At first IDLoc should be implemented, then perhaps "tumbler" and later other types. We should be able to use a lot of the XPath code in the XSLT module.

I now have CVS account, assigning XML linking related bugs to me (heikki@citec.fi).

Setting target milestone to Future so that this does not show up on PDT's radar...

Annozilla has a javascript implementation of XPointer, what's the motivation in expending development resources on implementing things which can easily be emulated in script? (I realise it's marked future so presumably not much actual work is going on, but you get the idea of the question I hope.)

We would need to take a look at the JS implementation to be able to say. Emulation may not be enough... But if there is a complete JS implementation which is fast enough, and made into an XPCOM component, I wouldn't care if it was written in JS.

Looking at the annozilla code, there are quite a few comments going "not yet supported". Anyway, what would we wanna do with the result of a xpointer? What should a js interface look like? Return a nsISelection? And what should happen with a #xpointer(foo) when viewed in the browser? We can't simply say GoToAnchor, should it just show the range set? In which order? Which stylesheets should apply? Those that are in the xml, or those that are in the selection? What should window.document look like? As xpointer can select just text, which CSS selectors would apply to such a node? I'd expect it to be styled as it is in the original document. xpointer can select fragments of text, so just setting the visibility with some CSS foo doesn't seem to cut it for me. Let alone that the xpath engine needs to learn about positions and ranges.

Since XPointer can return multiple range objects, the result needs to be able to handle them. Selection is one such possibility. When you follow an XPointer in browser, my proposal is to scroll to the first match and select (or style with CSS, I think CSS3 might have something about link target styling). Most of the other questions did not make sense to me. I don't see any problems there, think of normal links in HTML. XPointer works only on XML documents, although we could perhaps make it work on HTML as well, but the results would not be as predictable as with XML (think of all the residual style magic we do, and think what other browsers do in those cases).

alias for faster searching

I've just released the 0.1 version of an XPCOM service to create and evaluate XPointers at http://xpointerlib.mozdev.org/. I originally wrote this code as part of Annozilla, but it grew large enough that I thought it needed it's own home. It's a javascript implementation, and it doesn't implement complete XPointer yet. However, if I get some time I plan to implement more of the XPointer specification and more of the inherited XPath functions as well. At this point, it does handle all of the XPointers created by Annozilla and Amaya, though. Check it out, let me know what you think via either rainking@rice.edu or rhaptos@cnx.rice.edu.

I just noticed that libxml2 {http://xmlsoft.org/index.html} (which is shipped with most Linux distributions) is also portable (currently Linux, Solaris, Mac OS X, Windows binaries are available) supports most of XPointer, and a lot of other XML standards : * the XML standard: http://www.w3.org/TR/REC-xml * Namespaces in XML: http://www.w3.org/TR/REC-xml-names/ * XML Base: http://www.w3.org/TR/xmlbase/ * RFC 2396 : Uniform Resource Identifiers http://www.ietf.org/rfc/rfc2396.txt * XML Path Language (XPath) 1.0: http://www.w3.org/TR/xpath * HTML4 parser: http://www.w3.org/TR/html401/ * most of XML Pointer Language (XPointer) Version 1.0: http://www.w3.org/TR/xptr * XML Inclusions (XInclude) Version 1.0: http://www.w3.org/TR/xinclude/ * [ISO-8859-1], rfc2044 [UTF-8] and rfc2781 [UTF-16] core encodings * part of SGML Open Technical Resolution TR9401:1997 * XML Catalogs Working Draft 06 August 2001: http://www.oasis-open.org/committees/entity/spec-2001-08-06.html * Canonical XML Version 1.0: http://www.w3.org/TR/xml-c14n and the Exclusive XML Canonicalization CR draft http://www.w3.org/TR/xml-exc-c14n It is licenced under the MIT licence. If that is compatible with Mozilla licencing guidlelines, then perhaps using this library may speed the support of XPointer for Mozilla, and reduce duplication of effort in the open source world.

We know of libxml but un fortunately it is nontrivial to integrate it into Mozilla because of architectural issues.

Now that bug 182323 is fixed I think we can continue the discussion about this one. In my opinion the best and easier way to have the thing done is to modify the xpath parser of transformiix and teach it about points, ranges and location sets. Then, we can build a layer on its top and create new classes like nsXPointerEvaluator and etc. I wrote something about it and got it work in some way.. I still have to link my classes with the ones wrote by Heikki for bug 182323 (to which I have to propose some modifications) but it's some form of basis from where we can start, I think. If you are interested I can manage to make a patch for further discussions.

Do you really need to modify the xpath-parser? I had hoped that xpointer just added additional functions.

> In my opinion the best and easier way to have the thing done is to modify > the xpath parser of transformiix and teach it about points, ranges and location > sets. <peterv> eeeek and I second that. We have still quite some flux in transformiix, both on the architecture and performance side. Throwing new types in there is a bad thing for the upcoming changes. An *evaluation* of this has to wait until at least compilation and walker landed.

New types.. in truth the only modification that needs to be done (I presume) is to add a type LOCATIONSET in ExprResult and derive a new LocationSet object from ExprResult. I think that this will be sufficient to get the work done. There will be new functions, of course, but these will be derived from the Function object. I don't think that this will create performance problems or other.. Any way, excuse me if I came out from nothing with these posts but I have to get the work done for my thesis (sigh!) and I will like it if my work can be of any utility to you and mozilla :)

Marco et. al.: Yes, I would expect some modifications in the XPath engine to accommodate XPointer. I don't think it would be major changes, but some. The current XPointer API is the first version, so I would not be surprised if you have change suggestions to it. I think the correct schedule for the xpointer scheme landing would be mozilla 1.5alpha. Of course development should start before that, if possible. Marco, I'll reassign this to you for now.

This is my first tentative patch. It will not complete the work but it's the maximum I can do by myself right now :( This code creates a sort of infrastructure for the implementation of both the XPointer functions defined in the Working Draft and the ones people could want to make for their own schemes (by create a new nsXPointerFunctionLib object). The only function I have created is the covering-range one.. I didn't be able to make the others for some bugs I've found. I'll post these bugs in bugzilla asap. What it does is to create some new classes for the use within Transformiix, its original code hasn't been touched in an way except for minor adjustments like the ones to Makefiles, a new enum value for ExprResult and a couple of virtual keyword added to some methods. The patch (should) creates a new subdir in the Transformiix's tree, extensions/transformiix/source/xpointer, and all the code resides in that subdir but maybe some files can be moved to xmlextras with some work. I don't know. I think I haven't anymore to say now.. Please take a look to the patch and tell me if it can be helpful in some way. I'd really like to see this code in the tree.

Marco, this is awesome! First thing I noticed is that you want to change the licenses a bit - the Initial Developer in the new files isn't Netscape, it's you :) I'm not sure when I can have the change to try this out and review it properly, but I am very excited about this so thank you! The XSLT people will have to look at this code too, since it interfaces quite a bit with their code.

Comment on attachment 130227 [details] [diff] [review] First tentative patch tentative comments: prefix classes with something, either nsLocationSet or txLocationSet. the interface name should be nsIModifiableXPointer, no 'y'. According to spellbot. xpointer is only part of module, so the dir should be ifdefed in the Makefile.in (only added if you TX_EXE is not defined) mLocations should probably be an nsCOMPtr. Other members? Are there really underscores in the xptr function names? just skip those. Prefix the class names. xptr is not a prefix, at least we voted against xslt being a prefix. As heikki pointed out, look at the license plate. We favour triple license for newly added stuff. We favour nsAutoPtr for stuff like Expr* these days. I didn't see any other fundamental style things at a first glance. Oh, ah, yes. A unified diff would be great, folks are good at reading those and suck at anything else. I haven't yet looked at the transformiix interface changes at all yet.

- Added prefixes for all the classes. - Added TX_EXE checks in the Makefiles (or so I think :P) - Checked all the pointers and used nsCOMPtr or nsAutoPtr where possible - Removed all the _ from everywhere - Tried to create an unified diff (cvs diff -uN), but the output seems to me very similar to the standard one.. The licenses.. I used the mpl-tri-license-c boilerplate and took the copyright for everything: are other things wrong?

I forgot to say that I know that Modifyable is wrong spelled and should be written Modifiable, but don't blame me for this: Heikki created that class, so blame him :)

there had apparently been some discussions about overriding stuff in the ExprParser to be able to do range-to(). To do that we need to override both createLocationStep and isLocationStepToken. (/me shakes fist in general direction of xpointer for modifying the xpath syntax)

New version of my proposed patch, and it should now fully support the start-point(), end-point() and range-to() function, as long with the covering-range() one that ws developed time ago. A note for the range-to() function: since it is not accepted as a location step yet, a new syntax for the function as been created for testing purpose. You can specify the context node as an optional second parameter for the function: the code for the right behaviour does exist, even in this patch, but it's commented out waiting while waiting for the feature it needs.

This is my final patch. The work I was able to do have been done and I think it's time for others to check it. So, I request the review of this code. What remains to do is: - fix Transformiix XPath engine to accept range-to in location steps; - implement here() and origin(): I don't think it's possibile to have these work without changes in the XPath engine; - hard testing to check the completeness of the implementation

Comment on attachment 134974 [details] [diff] [review] Final patch Marco, when you request reviews you need to add the requestee email addresses as well. I put Jonas and Peter there for now, although Axel can also review the code in transformiix. I will try to take a look at this as well.

Updated patch to keep in sync with the latest changes in TransforMiiX. It's identical to the previous one in terms of features.

Comment on attachment 136002 [details] [diff] [review] Final patch #2 I can tell this already. A complete list will take a bit of time. The whole shebang with the functions needs to be redone. Like, txLocationSetFunctionCall should die, which obsoletes the changes to Expr.h, AFAICT. The function objects shouldn't cache their name atom, the atoms should be added to a static list. Not sure if they're supposed to be on a existing list, or if we should add a txXPointerAtoms. Peter? I know already that function resolving needs work (ie checking that the aNSid is kNameSpaceID_None (as that is the id for the namespace of the function name to be resolved)). I don't see the point in nsXPointerEvaluator, at least not in mimicing the xpath evaluator. As that is tuned to live on the document.evaluate, which can't be bound to two processors. (Note that I didn't read the patch fully yet, so I might be wrong here.) + nsCOMPtr<nsIXPointerResult> xptr = + do_CreateInstance("@mozilla.org/xmlextras/xpointerresult;1"); Smells like this is only available when xmlextras is there. Seems like this is the same for the xpath scheme, though. Does that make sense? As in, to not formally require it during the build. As I said, more to come.

Is there a rationale behind the (regrettable) WONTFIX?

Greg, yes. The decision was made that this would introduce too much complexity for too little gain.