161687 - Proposed XLink arc implementation

Status: RESOLVED WONTFIX

(Core :: XML, enhancement)

Description

[mozilla.org]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020722
BuildID:    2002072203

Current versions of Mozilla don't support XLinks of type "arc".  In addition to
the traditional outgoing link, arcs allow a document to make links between other
documents, or from other documents to itself.  I wish to encourage adding this
functionality.

Reproducible: Always
Steps to Reproduce:
Load an XML document with XLink arcs.  Observe nothing special.


It may not be clear in what situations arcs are useful, so I will describe a
particular application here that illustrates how one might use them.  (This
application is one I am actively working on, and in which I am currently forced
to work around the absence of arc support in Mozilla with less elegant tools.) 
I will also describe a way to find arcs reliably and safely and to display them
in the browser usefully.  I'll put all this in a subsequent attachment.

This is only a description of the user-level behavior I would like to see;  I
haven't yet dived into the Mozilla source, so I can't provide working code.  I'm
mostly looking for answers of the form "that would be nice, but we don't have
the time to do that now", "that would be nice, we'll get right on it", "that
idea is too lame to go in Mozilla", or "it should work this way instead".  From
there, I can figure out whether it's a sensible use of my time to try to grok
the Mozilla code and create a patch for this feature.

Comment 1

[mozilla.org]

[No, this is not an attachment, since it's not very much longer than the summary
after all.]

Why I want this:

I've written a short, simple program that marks up RFC 2822 messages and dumps
them into XML files with a simple DTD I've written.  A set of CSS stylesheets
accompanies them so you can usefully view them with Mozilla.  The intent is to
end up with a simple, extensible archive system for multiple mailing lists. 
I've gotten to the point where I want to add threading, group messages according
to which mailing list(s) they're in, and so on.  I'd like to do this entirely
with an external index so that adding a message to the system requires only
adding the message itself and (almost) appending some XLinks to an index
document.  The alternatives are:

* modify every message that needs to refer to the new message every time a
message arrives (adds complexity, slows down message injection, creates
potential for bugs), or

* give up on using static XML pages and dynamically generate things (adds
complexity, slows down message retrieval, creates potential for bugs, breaks
search engines unnecessarily).

Thoughts on how to do it:

The basic style of interface I'd like to see is a drop-down menu
(analogous to the ones next to the Forward and Back buttons) that
shows a hierarchy of XLinks leading away from this document (and maybe
another one showing XLinks leading to this document, so one can follow
them backward?).  This avoids the problem of where in the browser
window to place links derived from an external document, and provides
a familiar interface to users used to the Forward and Back buttons.

How do we find and select the links we want to include such that link
clutter is limited and untrustworthy third-party links can't get in or
are marked differently from trustworthy links?  If the document itself
contains XLinks with arcroles of "linkbase", it's reasonable to just
insert those linkbases into our XLink menus.  One could do a lot more
than that (e.g., using signed documents and a web of trust to assign
trust, picking up XLinks from the referring document or from known
canonical locations, and so on), but working linkbases would be a
great start.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So... this sounds very similar to the <link> element in HTML...  Could you not
reuse the link toolbar code for this?  That is, the link toolbar could include
XLinks such as the ones you describe, in addition to <link> elements....

Comment 3

[mozilla.org]

You're right, the Site Navigation Bar looks like just the right interface.  Too
bad it defaults to "Hide Always", so I hadn't seen it until you prompted me to
look for it---but that's for another bug report.

I now claim that the right thing to do is to populate the Site Navigation Bar
with the contents of the linkbase when we encounter
<...xlink:arcrole="linkbase"...> in an XML document.

This only accounts for arcs that lead away from the current document, but it's a
very good start and would solve my immediate problem.  Thanks!

Comment 4

[Alex Vincent [:WeirdAl]]

This bug is pretty old, still open, and doesn't really match the summary.  I 
don't see a proposed implementation of XLink's arc anywhere here.

Do we want to keep this bug open, or close it WORKSFORME or INVALID?  If we 
want to keep it open, it needs resummarizing at the least.