Return-Path: Mailing-List: contact general-help@xml.apache.org; run by ezmlm Delivered-To: mailing list general@xml.apache.org Received: (qmail 71743 invoked from network); 31 Mar 2000 11:24:00 -0000 Received: from pop.systemy.it (194.20.140.28) by locus.apache.org with SMTP; 31 Mar 2000 11:24:00 -0000 Received: from apache.org (pv30-pri.systemy.it [194.21.255.30]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id NAA04628 for ; Fri, 31 Mar 2000 13:23:55 +0200 Message-ID: <38E482A0.FDCDBD2F@apache.org> Date: Fri, 31 Mar 2000 12:49:04 +0200 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: it,en MIME-Version: 1.0 To: general@xml.apache.org Subject: Re: How to use XML to link to XML when the XML becomes HTML? References: <3.0.32.20000330074658.01a933a0@pop.intergate.ca> <38E36AF2.1789@es.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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 problem. 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 work. Possibilities: - "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 altogether? I mean: should those URI contracts be "enforced" as DTDs to the document writers? 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 /home/stefano/index 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. Comments? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- Missed us in Orlando? Make it up with ApacheCON Europe in London! ------------------------- http://ApacheCon.Com ---------------------