Re: [xslt] URIs and Their Hacks

[rm mh-freiburg de (Le grande pinguin)]

On Tue, Feb 18, 2003 at 05:43:10PM +0100, Igor Zlatkovic wrote:
> On Tue, 18 Feb 2003, Le grande pinguin wrote:
> > Hmm, maybe i put too much into symbol names (that's what you get from programming
> > in Scheme :) , but wouldn't  xmlCanonicPath be better name for that function?
> > After all, what the code does is a hashing from pathes to a unique path ....
> > This is an operation which seems neccesary on most plattforms that support relative
> > pathes, i guess.
> 
>   The name is of secondary importance for me, call it xmlCanonicPath for all
> I care :-) 

That's what i guessed :-)))
But really, i think programmers often underestimate the 'names' they use
in their APIs (with the exception of LISPers/Schemers, who can get pretty
mad on that topic). The name should represent the semantic as close as possible
(and your function creates a canonic form of a path (which happens to be the
URI-conforming version), not a mapping between path and URI, or?

> But, that functionality cannot completely be implemented on that
> level. The SAX handler startDocument (where this function is used) does not
> necessarily know anything about what it is actually parsing. Is it the
> document specified to xmllint on the command-line? Is it a document
> xincluded from another document? To build a really unique resource
> identifier there, one woud need to know if there is a base URI for the
> current document. That information is not available at the given level.

That was my understanding. The function _can't_ create a URI, it creates
a canonic path (a canonic textual representation that allows tests for
equalness).

>   The purpose of xmlURIFromPath is therefore not uniqueness, but
> URI-conformness. 

Is it really? Don't you want to test whether two resorces map to the same
path (so you do not need to reparse them)?

> If what xmlDoc.URL holds is not an URI, subsequent
> manipulations through the functions from uri.c will fail. When, for example,
> one document xincludes ahother and the corresponding code tries to build the
> URI for the included document, it will fail if the xmlDoc.URL of the
> including document is, say, a Windows path.
> 
>   The other thing, namely ensuring that more occurences of the same document
> are represented by the same URI, that's another front.
> 
> > ... do they even _have_ to be paths? After all libxml has a pluggable IO layer
> > (we use cms://bla/fup/oink .... inhouse :-)
> 
> And what you use is a proper URI :-) As said, IO layer has little to do with
> this. The purpose is to ensure that URI processing regarding linked
> documents succeeds in every case.

But IO-Layer is what deals with 'path'. The "semantic" (excuse the word, i'm writing this
from the semantic web Infotag ;-) of an URI depends on it's shema http/ftp/file/foop/snord ...
only the IO-layer can decide whether two URIs point to the same resource.

> > Hmmm, thinking of that -- i think a real clean API would have a 'xmlCanonicURI'
> > function as part of the IO layer ....
> 
> Everything will come in due time :-)

Ok, i'll shut up. Time for a beer.

  Ralf
> Ciao,
> Igor
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt@gnome.org
> http://mail.gnome.org/mailman/listinfo/xslt