Last Comment Bug 32832 - (xpointer) Implement XPointer
(xpointer)
: Implement XPointer
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: All All
: P3 enhancement with 10 votes (vote)
: mozilla1.6alpha
Assigned To: Marco Giovannini
:
Mentors:
: 478378 (view as bug list)
Depends on: 10292 182323 235409
Blocks: 88092 12305
  Show dependency treegraph
 
Reported: 2000-03-22 04:49 PST by Heikki Toivonen (remove -bugzilla when emailing directly)
Modified: 2014-09-16 11:35 PDT (History)
29 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
First tentative patch (83.15 KB, patch)
2003-08-22 06:58 PDT, Marco Giovannini
no flags Details | Diff | Review
Simple testcase document (8.10 KB, text/xml)
2003-08-25 09:08 PDT, Marco Giovannini
no flags Details
Second tentative patch (73.42 KB, patch)
2003-08-25 09:20 PDT, Marco Giovannini
no flags Details | Diff | Review
Third patch (88.70 KB, patch)
2003-11-04 08:10 PST, Marco Giovannini
no flags Details | Diff | Review
Final patch (98.83 KB, patch)
2003-11-07 06:01 PST, Marco Giovannini
no flags Details | Diff | Review
Final patch #2 (99.38 KB, patch)
2003-11-20 10:11 PST, Marco Giovannini
axel: review-
Details | Diff | Review

Description Heikki Toivonen (remove -bugzilla when emailing directly) 2000-03-22 04:49:55 PST
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.
Comment 1 Heikki Toivonen (remove -bugzilla when emailing directly) 2000-04-11 01:29:21 PDT
I now have CVS account, assigning XML linking related bugs to me 
(heikki@citec.fi).
Comment 2 Nisheeth Ranjan 2000-05-24 18:07:53 PDT
Setting target milestone to Future so that this does not show up on PDT's 
radar...
Comment 3 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-02-01 10:57:56 PST
http://www.w3.org/TR/xptr/
Comment 4 Jim Ley 2002-07-11 03:58:45 PDT
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.)

Comment 5 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-07-11 09:37:42 PDT
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.
Comment 6 Axel Hecht 2002-08-19 04:01:20 PDT
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.
Comment 7 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-08-19 11:06:37 PDT
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).
Comment 8 Kai Lahmann (is there, where MNG is) 2002-08-21 15:24:43 PDT
alias for faster searching
Comment 9 Doug Daniels 2002-11-20 11:48:16 PST
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.
Comment 10 Padraig OhIceadha 2003-02-18 05:56:29 PST
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.
Comment 11 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-02-18 11:26:48 PST
We know of libxml but un fortunately it is nontrivial to integrate it into
Mozilla because of architectural issues.
Comment 12 Marco Giovannini 2003-03-20 02:54:27 PST
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.
Comment 13 Jonas Sicking (:sicking) 2003-03-20 05:45:15 PST
Do you really need to modify the xpath-parser? I had hoped that xpointer just
added additional functions.
Comment 14 Axel Hecht 2003-03-20 05:47:10 PST
> 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.
Comment 15 Marco Giovannini 2003-03-20 07:02:23 PST
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 :)
Comment 16 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-03-20 14:10:06 PST
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.
Comment 17 Marco Giovannini 2003-08-22 06:58:15 PDT
Created attachment 130227 [details] [diff] [review]
First tentative patch

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.
Comment 18 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-08-22 12:36:50 PDT
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 19 Axel Hecht 2003-08-22 14:05:41 PDT
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.
Comment 20 Marco Giovannini 2003-08-25 09:08:28 PDT
Created attachment 130366 [details]
Simple testcase document
Comment 21 Marco Giovannini 2003-08-25 09:20:05 PDT
Created attachment 130368 [details] [diff] [review]
Second tentative patch

- 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?
Comment 22 Marco Giovannini 2003-08-25 10:57:18 PDT
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 :)
Comment 23 Jonas Sicking (:sicking) 2003-10-14 11:20:15 PDT
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)
Comment 24 Marco Giovannini 2003-11-04 08:10:03 PST
Created attachment 134766 [details] [diff] [review]
Third patch

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.
Comment 25 Marco Giovannini 2003-11-07 06:01:06 PST
Created attachment 134974 [details] [diff] [review]
Final patch

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 26 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-11-07 15:00:10 PST
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.
Comment 27 Marco Giovannini 2003-11-20 10:11:38 PST
Created attachment 136002 [details] [diff] [review]
Final patch #2

Updated patch to keep in sync with the latest changes in TransforMiiX.
It's identical to the previous one in terms of features.
Comment 28 Axel Hecht 2003-11-23 10:37:56 PST
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.
Comment 29 Robert Longson 2009-02-13 03:23:24 PST
*** Bug 478378 has been marked as a duplicate of this bug. ***
Comment 30 Greg K. 2012-11-30 02:31:25 PST
Is there a rationale behind the (regrettable) WONTFIX?
Comment 31 Boris Zbarsky [:bz] 2014-09-16 05:27:24 PDT
Greg, yes.  The decision was made that this would introduce too much complexity for too little gain.

Note You need to log in before you can comment on or make changes to this bug.