Closed Bug 15086 Opened 21 years ago Closed 20 years ago

FEATURE: Implement simple links based on the XLink spec.


(Core :: XML, defect, P3)






(Reporter: nisheeth_mozilla, Assigned: hjtoi-bugzilla)



(Keywords: helpwanted, Whiteboard: [nsbeta2+][5/16] Fix in hand.)


(6 files)

We need simple links as defined in the XLink spec
( to make XML usable in a
standards conformant way.
Target Milestone: M14
I'm keeping this development post beta for now.  Will bring it in if time
Adding vidur and troy to the cc list...
Whiteboard: HELP WANTED
Adding Heikki Toivonen to the cc list.  Heikki's worked on implementing linking
in doczilla and is intimately familiar with the mozilla codebase.  Heikki, I
remember that you had sent out a message about linking to the layout newsgroup.
Do you have any comments/code to help us implement this feature?

Thanks a lot for your help.
The basic links in SGML and XML are ID/IDREF(S) type links. However, these
cannot be implemented in Mozilla if the XML parser does not pass us information
about the DTD. Below is a sample of these links:

<!DOCTYPE doc [

<!-- note ID *type* attribute -->
          unique-id ID #IMPLIED

<!-- note IDREFS (a plural for IDREF, can have multiple targets) *type* -->
<!ATTLIST xref
          ref IDREFS #REQUIRED
<p unique-id="id-foo">Foo para</p>
<p>Here is a <xref ref="id-foo">link</xref>.</p>

The basics of simple XLink support are there already. However, the checking if
something is a link is done for each attribute. This is wrong and inefficient.

Ideally, when we are reading the document or creating new elements dynamically,
the checking should happen when we see start tag close '>'. At this point we
have the element name and all the attributes. Additionally, if at some point we
will get DTD support we can now check default attributes from the DTD (or maybe
XML Schema in the future).

This is also a lot faster than doing this per attribute. With the latest XLink
spec we may need to check several attributes to make sure it is a link so if we
only check one attribute at a time we may never realize something is a link.

Of course, if we are just changing/adding/removing an attribute dynamically
after the document has loaded we need to see if it changes the "linkness".

The XLink attributes beyond href are also a bit problematic. show='parsed' means
the target "content should be integrated into the document from which the link
was actuated". But what does this really mean? Should the content replace the
linking element, appear as it's child or appear as content but not in the same
document tree? I believe the latter seems to be the most commonly understood
form. With Mozilla I guess it would mean create an iframe for the new content
and show it there. But should this new iframe conceptually replace the linking
element or appear as it's child? Of course you could run into problems with

One possible use of the parsed value in the attribute would be to include images
in a document. This way you would not need to use the HTML IMG tag in XML. There
is also another way to indicate that an element should display images but that
(again) requires access to the DTD information.

The spec also does not exactly say how role and title attributes should be
handled, but I guess they are not that big an issue. In any case, the behaviour
should be somewhat consistent with what other systems are doing.

actuate='auto' is quite interesting. The spec says "automatically initiated when
the application deems that the user has reached the link". I guess scrolling to
the link or showing a page where the link is visible counts as "reached" the

I believe XPointers should be considered as well. The full XPointer spec (and
XPath) implementation would be quite a lot of work, but just implementing two
features would be a great leap forward. These are IDLoc and Tumblers, although
IDLoc (again) cannot be properly implemented if we do not get DTD information.

A tumbler will let us point to any node in a document. The syntax is simple.
"/1/3/2" would first locate the document root element ("/1"), the 3rd child
element of that ("/3") and then the 2nd child element of that ("/2") which would
be the final target.

The XPointer module could be pretty much standalone component.

The problems with XPointers arise when you begin to think what would need to
change to make them work seamlessly with the rest of the code. I do not think
there is DOM support for them yet.

Thinking about XPointers now will save us a lot of trouble in the future. For
example, XPointers can address single elemets, spans, lists, discontinuous
regions of text etc.

As a final word of caution I think we should not lock ourselves into simple
XLinks only. The more powerful extended links will need to be implemented
eventually, and if we can, we should not make it more difficult than necessary.

Unfortunately I do not have any code I could give out at this time, it is all
copyright Citec. We have the following kinds of links working in DocZilla:
ID/IDREF(S), simple XLinks (not totally according to the latest spec), XPointers
(IDLoc and tumbler), HyTime clinks (analoguous to simple XLinks) with nameloc,
treeloc and URL queryloc locators (analoguous to IDLoc, tumbler and HTML URL
but you can form location paths and ladders by combining several locators, a
bit like HTML redirection).

I am interested in seeing good linking support in Mozilla as well so I will help
as much as I can.
This isn't in simple links, but I decided to write it down someplace.

In the MozillaZine chat someone was wondering how you would present links with
multiple targets. In Multidoc Pro
( we do this by formatting the
link as any other link. Clicking on the link will bring up a popup list listing
all the targets of the link. This works very well if you know the final
targets of the links.

If you have a link with multiple targets, select one, and again are faced with
branching link, the popup menu is perhaps not that good. I guess normal dialog
lilsting linkends would then be more appropriate. If the link branches multiple
times (and we do not know this at the time of displaying the first dialog) the
user will be presented with several dialogs *but they will all be similar

Sometimes displaying the link targets by URI is not the best solution. The role
attribute information could perhaps be used, or (in the future?) it could be
possible to specify this in a stylesheet.

In Mozilla multiple targets should also be indicated in the status bar.
Patches upgrade us to the latest draft

I finally had some time to take a look at this. I did not try to do any
optimization. I just put everything in plain sight. I did not do heavy testing,
but the few tests I tried seemed to function OK.

While I was there, I fixed a couple of dangerous looking things in other places
in nsXMLElement.cpp.

If/when these patches will be applied, all the XML files (XUL, demos etc.)
should be checked and changed to the latest XLink draft.
This should probably take bug 6306 into account as well...
OS: Windows NT → All
Because this affects the new webshell design I added to CC.
I thought of putting the [WebShell] to summary line but it already has FEATURE
and if I add [WebShell] it gets too long.

This bug affects the webshell because currently webshell implements the
nsILinkHandler interface. I believe eventually the link handler must be a
component of its own that can even manage a link database if it needs to. This
might be needed when we implement extended XLinks.

We have most of the link handling happen in fact in the *Element.cpp files, so
that webshell is only used for displaying messges in the status bar and loading
URLs. When we need to find a ref in a document, presshell does that.
I am trying to collect all relevant information into the same place which is
why I keep adding stuff here.

I asked from Keith Visco (XSLT module owner):

> How difficult would it be to use the XPath handling
> provided by the XSLT package elsewhere, so that it could be enhanced with
> special XPointer constructs and used by the XLink code?

I think it should be fairly straight forward. I have been meaning to perform
better separation of XPath from the XSLT processor, but you should be able to
use the expr library without needing the rest of the XSLT processor. However you
will most likely need the DOM implementation provided with the XSLT processor.
Bulk moving all M14 non-beta stopper bugs to M17...
Target Milestone: M17 → M14
I want to get this in before beta.  Moving in milestone to M14...
These XML bugs need to move to M15, unfortunately.  These aren't beta 1 stoppers 
and I have to pull in other more critical bugs from Kipp's plate for beta 1.
Target Milestone: M14 → M15
The beta 1 criteria lists specifically 'XLink: support "simple" links only'
Keywords: beta1
Keywords: helpwanted
Whiteboard: [PDT-] HELP WANTED → [PDT-]
There are still some documents at that use the old XLink draft, see:

There may be other cases as well, I am trying to find out if there needs to be
more changes to other XML files. Of course this checking would break all links
anywhere on the web that use the old XLink spec, but I see this as no big
damage, after all it is a WD. And many people already asked why Mozilla did not
support the 1999-07-26 draft. Most should be looking at the latest draft.

I expect the XLink namespace to change once the XLink spec becomes
recommendation, but other than that I think this could be pretty close to a
working fix.

There are still attributes and attribute values that are not yet implemented,
like the embed value of show as well as actuate="onLoad".

nisheeth, what do you think about checking this in? I can't do this yet myself
(I am just applying for CVS checkin rights). If you show green light, might be able to do it if you are too busy. 

After I get checkin rights I could take over the XML linking related bugs if
that would be ok.
I am ok with jst checking this in.  Before we do that, we should make sure that 
our XUL files use the XLinks format specified in the latest WD.

Heikki, please feel free to take over the XLink related bugs.  I really 
appreciate your help and initiative.  Thanks.
I did not find any XUL files where XLink was used. I also searched with LXR from 
the whole Mozilla tree:

It found those rights.xml and books.xml XML demos, a stylesheet, a JavaScript 
file and docbooktest.xml, which is propably bogus anyway. probably does not automatically update from the normal Mozilla 
CVS tree, so changes in those example files would be needed elsewhere as well(?)

I'll attach the patch for those files LXR found (by the way, sorry about the 
crap in the beginning of 03/23/00 05:53 patch). One thing I am not sure about is 
the JavaScript, i.e. does:

newTocElement.setAttribute("xlink:type", "simple");

properly put the link attribute in the xlink namespace? If not, then this needs 
a bit more work. Can't test this right now.
I saw your request to leaf for checkin privileges.  I'm re-assigning this bug to 
you so that you can mark it fixed once you checkin your patches.  You've done 
all the work on this bug and the credit for fixing it should go to you...
Assignee: nisheeth → heikki
I really want to get this in for M15...  Taking this back from heikki.
Assignee: heikki → nisheeth
The patch to the code and the demos in mozilla tree is checked in.
Marking fixed.
Closed: 20 years ago
Resolution: --- → FIXED
Reopening as we do not yet completely implement simple XLink (missing handling 
of some attributes, and XML Base support is not yet checked in).
Resolution: FIXED → ---
I now have CVS account, assigning XML linking related bugs to me 
Assignee: nisheeth → heikki
PDT- removed from beta1; nsbeta2 added.
Keywords: nsbeta2
Whiteboard: [PDT-]
How come this is still M15? M15 is already out!
Putting on [nsbeta2+] radar.  But MUST complete work by 05/16 or we may pull 
this feature for PR2.
Whiteboard: [nsbeta+][5/16]
Upating [nsbeta2] to read [nsbeta2+] in Status Whiteboard.
Whiteboard: [nsbeta+][5/16] → [nsbeta2+][5/16]
Set the milestone to M16.

I have implemented at least partially the actuate="onLoad" (automatically 
trigger this link as soon as it has been recognized) in my tree, but I want to 
clean it up a bit.

I also have a question: is this automatic link triggering some kind of event? 
Should it be possible to override it with scripts or something? Script override 
might be a bit unreliable with race conditions, because some script that might 
want to override this may not be loaded at the time this link triggers 
(assuming it is overridable at all)., please note that simple XLink support has been in Mozilla 
for perhaps a year already. We have never supported all the simple XLink 
attributes. I am just implementing support for them. So it is kinda strange 
saying simple XLink support would be pulled from PR2... And we do support all 
the mandatory requirements specified in the XLink spec. 

I am not sure if it can be said that Mozilla is a conforming XLink application 
(as far as simple link is considered), but we are close. I will make sure we 
won't do anything stupid with "unimplemented" attributes.

XLinks are also extensible, meaning that in addition to offering all the things 
defined in the spec we should ideally provide some kind of interface for 
plugging in third party link/link attribute handlers. I don't think this is high 
priority, and they should not keep this bug open.
Target Milestone: M15 → M16
Checked in code to handle actuate="onLoad".

Nisheeth, I did this the link click way. We must explicitly tell the parser then 
to stop if we have replace link, because link click produces an event, and the 
event(s) will be handled after the document has loaded (or at least a large 
chunk of it has loaded). If we do not stop, we could have several replace links 
in the event queue.

I also noticed we wouldn't necessarily need to do the security check here, 
because it will also happen in the nsGenericElement::TriggerLink(). 
Unfortunately it does not return any information if the trigger was legal or 
not. That could be changed, though.

Test file in layout/xml/tests/xml/auto.xml.

FYI: show="new" does not seem to open a new window for XLinks, I do not think it 
has ever worked. I think that if this was fixed we would then have a conformant 
XLink application (limited to simple XLink). The show attribute handling is not 
a *must* in the spec, so we could say we have conformant implementation even 
Oops, that last /xml/ in the sample file path should be /xlink/
I have a fix in my tree which will open show="new" links in a new window. Tree 
is now closed, so gotta wait... The strange thing is I am sure I tried this 
earlier yet it did not work.
Updating status whiteboard, per Heikki's comments
Whiteboard: [nsbeta2+][5/16] → [nsbeta2+][5/16] Fix in hand.
I checked in the code to enable show="new". Unfortunately it does not work 
together with actuate="onLoad".

Summary of features:

  We recognize this is a simple XLink
  Get the href to traverse to. If empty, do nothing.
  Doing nothing with this.
  Doing nothing with this, but want to show tooltip, see bug 1995. Should
  now be simple to do.
    Open in new window, unless there is also actuate="onLoad", in which case
    this acts like show="replace". That is a bug.
    Open link in same window. If there is actuate="onLoad", will stop
    further document processing, i.e. first such link wins in a document.
   Treat as show="replace", unless there is also actuate="onLoad", in
   which case do nothing with this link automatically. Will still function
   as replace link when clicked. Want to implement this so that it "replaces"
   the linking element, i.e. the target's content should appear in the links
   place. This will require quite a bit work. Even the spec is vague about
   the implementation. Many issues.
   Treat as "replace".
  =<any other value>
   Treat as "undefined".
    Act when the link is clicked.
    Act when the link is loaded. See also show attribute.
    Treat as "onRequest".
  =<any other value>
    Treat as "undefined".

Attributes role, show and actuate can take a qualified name as argument. 
Eventually we could implement an extensible interface
for plugging in handlers for these. For example, if the value was
qualified name "mozilla:preload", we might have a MozillaXLinkPreloadHandler
that would load the link target into cache on idle time.

Links to refs in XML documents do not work. This is not strictly an area of 
XLink, but more like XPointer. For the generic case this will require the new 
Expat parser so that we get information about ID attributes. For now we could 
implement the GetElementById() to locate HTML A elements if they have id or name
attributes set.

I do not know what should be done with this bug. Mark this fixed? In my opinion 
we could say we have conformant simple XLink implementation so marking fixed is 
one option. We could open new bugs for the missing parts. Or keep this open 
until some more optional arguments are implemented. Or keep this open till all 
qualified handler interfaces are implemented as well, i.e. more like tracker 
bug. Opinions?
Great work, Heikki.

I think you should mark this bug fixed and open new bugs for the other issues 
that you have identified.  We now have a conformant "simple" XLinks 
implementation thanks to your hard work.  The other bugs are smaller issues that 
are lower priority and should be tracked separately.
Marking fixed.

Created bugs for embed, show="new" + actuate="onLoad", pluggable qualified name 
handlers. Title attribute will be taken care of by bug 1995.
Blocks: 39597, 39598, 39600
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
With the May 22nd builds, simple xlink support is functioning correctly.
You need to log in before you can comment on or make changes to this bug.