15086 - FEATURE: Implement simple links based on the XLink spec.

Status: VERIFIED FIXED

(Core :: XML, defect, P3)

Description

[Nisheeth Ranjan]

We need simple links as defined in the XLink spec
(http://www.w3.org/TR/WD-xlink.html#simple-links) to make XML usable in a
standards conformant way.

Comment 1

[Nisheeth Ranjan]

I'm keeping this development post beta for now.  Will bring it in if time
permits.

Comment 2

[Nisheeth Ranjan]

Adding vidur and troy to the cc list...

Comment 3

[Nisheeth Ranjan]

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.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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 -->
<!ATTLIST p
          unique-id ID #IMPLIED
>

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

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
scripts.

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
link.

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.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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
(http://www.citec.fi/company/it/mdp/index.html) 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
dialogs*.

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.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Simple XLink according to the 1999-07-26 draft (latest)

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Small changes needed in nsILinkHandler and webshell as well

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 9

[Hixie (not reading bugmail)]

This should probably take bug 6306 into account as well...

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Because this affects the new webshell design I added [e-mail] 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.

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 12

[Nisheeth Ranjan]

Bulk moving all M14 non-beta stopper bugs to M17...

Comment 13

[Nisheeth Ranjan]

I want to get this in before beta.  Moving in milestone to M14...

Comment 14

[Nisheeth Ranjan]

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.

Comment 15

[gerardok]

The beta 1 criteria lists specifically 'XLink: support "simple" links only'

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Simple XLink WD 21 Feb 2000

Comment 17

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix for rights.xml (debug demo 15)

Comment 18

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix for books.xml (debug demo 14)

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

There are still some documents at mozilla.org that use the old XLink draft, see:

http://www.mozilla.org/newlayout/xml/

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,
jst%netscape.com 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.

Comment 20

[Nisheeth Ranjan]

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.

Comment 21

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I did not find any XUL files where XLink was used. I also searched with LXR from 
the whole Mozilla tree:

http://lxr.mozilla.org/mozilla/search?string=xml%3Alink

It found those rights.xml and books.xml XML demos, a stylesheet, a JavaScript 
file and docbooktest.xml, which is propably bogus anyway.

www.mozilla.org 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.

Comment 22

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Fix for all instances of XLink in mozilla

Comment 23

[Nisheeth Ranjan]

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...

Comment 24

[Nisheeth Ranjan]

I really want to get this in for M15...  Taking this back from heikki.

Comment 25

[Nisheeth Ranjan]

The patch to the code and the demos in mozilla tree is checked in.

Comment 26

[Nisheeth Ranjan]

Marking fixed.

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Reopening as we do not yet completely implement simple XLink (missing handling 
of some attributes, and XML Base support is not yet checked in).

Comment 28

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I now have CVS account, assigning XML linking related bugs to me 
([e-mail]).

Comment 29

[Christine Hoffman]

PDT- removed from beta1; nsbeta2 added.

Comment 30

[moshev]

How come this is still M15? M15 is already out!

Comment 31

[leger]

Putting on [nsbeta2+] radar.  But MUST complete work by 05/16 or we may pull 
this feature for PR2.

Comment 32

[leger]

Upating [nsbeta2] to read [nsbeta2+] in Status Whiteboard.

Comment 33

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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).

[e-mail], 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.

Comment 34

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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 
now.

Comment 35

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Oops, that last /xml/ in the sample file path should be /xlink/

Comment 36

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 37

[Nisheeth Ranjan]

Updating status whiteboard, per Heikki's comments

Comment 38

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I checked in the code to enable show="new". Unfortunately it does not work 
together with actuate="onLoad".

Summary of features:

type="simple"
  We recognize this is a simple XLink
href
  Get the href to traverse to. If empty, do nothing.
role
  Doing nothing with this.
title
  Doing nothing with this, but want to show tooltip, see bug 1995. Should
  now be simple to do.
show
  ="new"
    Open in new window, unless there is also actuate="onLoad", in which case
    this acts like show="replace". That is a bug.
  ="replace"
    Open link in same window. If there is actuate="onLoad", will stop
    further document processing, i.e. first such link wins in a document.
  ="embed"
   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.
  ="undefined"
   Treat as "replace".
  =<any other value>
   Treat as "undefined".
actuate
  ="onRequest"
    Act when the link is clicked.
  ="onLoad"
    Act when the link is loaded. See also show attribute.
  ="undefined"
    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?

Comment 39

[Nisheeth Ranjan]

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.

Comment 40

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Marking fixed.

Created bugs for embed, show="new" + actuate="onLoad", pluggable qualified name 
handlers. Title attribute will be taken care of by bug 1995.

Comment 41

[Chris Petersen]

With the May 22nd builds, simple xlink support is functioning correctly.