Closed Bug 32832 (xpointer) Opened 21 years ago Closed 10 years ago

Implement XPointer


(Core :: XML, enhancement, P3)






(Reporter: hjtoi-bugzilla, Assigned: giovanni)




(2 files, 4 obsolete files)

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.
Depends on: 15086
Target Milestone: ---
I now have CVS account, assigning XML linking related bugs to me 
Assignee: nisheeth → heikki
Setting target milestone to Future so that this does not show up on PDT's 
Target Milestone: --- → Future
QA Contact: chrisd → petersen
Target Milestone: Future → mozilla1.2
No longer depends on: 15086
Target Milestone: mozilla1.2 → Future
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
alias for faster searching
Alias: xpointer
I've just released the 0.1 version of an XPCOM service to create and evaluate
XPointers at  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 or
QA Contact: petersen → rakeshmishra
I just noticed that libxml2 {} (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:
    * Namespaces in XML:
    * XML Base:
    * RFC 2396 : Uniform Resource Identifiers
    * XML Path Language (XPath) 1.0:
    * HTML4 parser:
    * most of XML Pointer Language (XPointer) Version 1.0:
    * XML Inclusions (XInclude) Version 1.0:
    * [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:
    * Canonical XML Version 1.0: and the Exclusive
XML Canonicalization CR draft

   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
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.
Assignee: heikki → giovanni
Severity: normal → enhancement
Target Milestone: Future → mozilla1.5alpha
Summary: FEATURE: Implement XPointer → Implement XPointer
QA Contact: rakeshmishra → ashishbhatt
Attached patch First tentative patch (obsolete) — Splinter Review
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

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

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
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.
Target Milestone: mozilla1.5alpha → mozilla1.6alpha
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

xpointer is only part of module, so the dir should be ifdefed in the (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.
Attached patch Second tentative patch (obsolete) — Splinter Review
- 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?
Attachment #130227 - Attachment is obsolete: true
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)
Attached patch Third patch (obsolete) — Splinter Review
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.
Attachment #130368 - Attachment is obsolete: true
Attached patch Final patch (obsolete) — Splinter Review
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
Attachment #134766 - Attachment is obsolete: true
Attachment #134974 - Flags: review?
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.
Attachment #134974 - Flags: superreview?(peterv)
Attachment #134974 - Flags: review?(bugmail)
Attachment #134974 - Flags: review?
Attached patch Final patch #2Splinter Review
Updated patch to keep in sync with the latest changes in TransforMiiX.
It's identical to the previous one in terms of features.
Attachment #134974 - Attachment is obsolete: true
Attachment #136002 - Flags: superreview?(peterv)
Attachment #136002 - Flags: review?(bugmail)
Attachment #134974 - Flags: superreview?(peterv)
Attachment #134974 - Flags: review?(bugmail)
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.
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

+    nsCOMPtr<nsIXPointerResult> xptr =
+      do_CreateInstance(";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.
Attachment #136002 - Flags: superreview?(peterv)
Attachment #136002 - Flags: review?(bugmail)
Attachment #136002 - Flags: review-
Depends on: 235409
Attachment #130366 - Attachment mime type: text/plain → text/xml
Duplicate of this bug: 478378
QA Contact: ashshbhatt → xml
Closed: 10 years ago
Resolution: --- → WONTFIX
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.
You need to log in before you can comment on or make changes to this bug.