xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: How to use XML to link to XML when the XML becomes HTML?
Date Fri, 31 Mar 2000 10:49:04 GMT
Dan Morrison wrote:
> Tim Bray wrote:
> > What you're doing is transforming links as part of the publishing or
> > delivery process.  A common-enough thing to want to do.  If XSLT has
> > trouble in doing what you want, then that is probably a shortcoming
> > of XSLT.  XLink is just syntax for describing links, not a framework
> > for transforming them. -Tim
> I just want my link relationships to be stated in a generic enough way
> to survive a global change of suffix.
> I take this to mean that I should work on leveraging my XSLT to mess
> around with href attributes s/\.xml$/\.html/ etc. OK, I didn't want to
> be playing with substrings (which sure is a shortcoming with XSL) but
> I'll manage.
> I therefore take it that Xlink can draw no implicit relationship at all
> between doc.xml and doc.html without such a relationship being stated on
> a one-by-one basis in some external link file.
> The filenames are different, therefore they are different objects. It'd
> be fun if I could throw some wildcarding into the filename but my
> reading of the spec didn't see that.
> ... hmm, what if I set up a directory structure with every 'file' being
> a directory containing multiple versions of the same content then used
> content negotiation to... [shudder]. Yuk.
> I'm looking forward to using the extended link syntax for
> cross-referencing keyword lookups, but I've never seen a UI that does
> this. Has anyone ever made an example of practical, multi-targeted
> extended links (beyond content-negotiation)?

This is a big issue and I still don't have a clear-cut vision on the

I hope that others (Tim at first) can share opinions over this one which
is a very nasty issue.

Situation: consider you are a site manager and you tell your document
writers to write XML documentation. You give them the DTD/Schema and you
tell them what they should write. Suppose they need to link each-other


 - "hard" link points to "doc1.xml"
 - "soft" link points to "doc1.xml"

this can be done with [role="hard|soft"] as an attribute of your
XLink-ed element.

"Hard" means that the link is not touched, while "soft" means that the
link has a meaning in the context of document writing: doc2.xml knows
that the file name on the dist is doc1.xml, but doesn't know where the
document will reside after deployment on the publishing URI space.

So, by allowing "soft" links on the server side, we remove a "contract"
between the site managers and the document writers.

Still questions remain on "how" link translation is performed, but this
is an implementation detail.

The question is: do "soft" links break the hyperlinking paradigm

I mean: should those URI contracts be "enforced" as DTDs to the document

NOTE: don't get me wrong, this is _NOT_ a discussion about "extention
translation" like written above. That arguments doesn't count: you
should _NEVER_ use extentions in your URIs and if you do you're not
getting the URI idea alltogether.

Browsers should access


and publishing engines (apache + cocoon) should take care of mapping
this "resource" to the appropriate generation procedure. If this
requires loading the file "index.xml" or "default.htm" or even accessing
the index from a database and generate the XML from there, this is _NOT_
a concern that who writes the index.xml file should have.

And links are _NOT_ something that you should mess around with with
something like XSLT processors.

The idea is to have links on the server side that are "streched" while
being published to match the URI space.

And I'm not sure this is a good thing to do.


Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message