[4suite-dev] checkin - URIs URIs URIs

Uche Ogbuji uche.ogbuji at fourthought.com
Sun Dec 15 19:24:57 MST 2002


On Sun, 2002-12-15 at 18:48, Mike Brown wrote:
> The following URI related changes are checked in.
> Things seem to work, but who knows; I probably broke everything.
> Give things a shot and see how they do.
> 
> The two big consequences are:
> 
> 1. From within the repo, the local filesystem is now inaccessible
> via a URI. 'file' URIs are now repo references only (when such URIs
> are encountered in a document in the repo).
> 
> 2. We already were moving in this direction, but now it is especially
> important: when your document has URI references in it, you have to
> ensure that the document's URI is established, so that these references
> can be resolved using that URI as the base, when necessary.
> 
> Regarding #1, obviously this is going to break things for Evan and Uche (as
> per Uche's post the other day), but from a security standpoint I think it's
> better to start from the POV that the system is closed and then think about
> where and how to open it up, then to leave the gaping hole and be coming up
> with ad-hoc plugs.

I am not averse to starting with local access closed, but this doesn't
mean it is OK to interpret file: URLs as repo paths.  As I've said, I do
not want to do this because I think it is confusing considering that
there is a local file system that people will at least have in mind.

For example, as we do come to allow access to a file system based on
security policy, how will we disambiguate access to the file system from
access to the repo?

As such, as things stand, I would request that you back out change #1. 
Or at least back out the part that translates file: URLs into repo
paths.  I can accept just completely disabling file: for now.

Or perhaps you have other justification for the change that I'm missing?


> I'm leaning toward a completely unambiguous URI scheme, one that
> always means local filesystem, not repo. But I can also see the advantage
> of being able to flip a switch to change the meaning of the 'file' scheme.

I'm confused.  But you checked in a completely unambiguous scheme that
is the exact opposite of what you say above.  Or are you meaning that
this "completely unambiguous" scheme is somethign other than file:?


> What are the use cases where real filesystem access is needed?
> Apparently EXSLT's <exsl:document/> is one that people are depending on...

exslt:document is one.  The other obvious one is xsl:document, where you
want a doc from the file system or LAN.  These two cover all the cases
that I know of, but I haven't done any study of likely cases.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
A Python & XML Companion - http://www.xml.com/pub/a/2002/12/11/py-xml.html
XML class warfare - http://www.adtmag.com/article.asp?id=6965
MusicBrainz  metadata - http://www-106.ibm.com/developerworks/xml/library/x-think14.html




More information about the 4suite-dev mailing list