RE: Multiple result-documents, client-side transformations, and U RIs

> 
> Hi Michael et al,
> 
> I'm peer of XSLT in Mozilla and would like to give my own two 
> cents on 
> the ideas around xsl:result-document in a webbrowser environment.

Thanks for your note, this is very useful input.

> 
> Upfront, I really like the idea of having multiple output 
> documents in a 
> publishing and maybe even a server environment.
> 
> In a webbrowser on the other hand, xsl:result-document raises quite a 
> few issues on the sandbox. One issue is already dealt with, making 
> absolut URIs in xsl:result-document having implementation defined 
> constraints.
> Reading the WD-xslt20-20030502, I don't see the chance to have 
> implementation defined constraints for relative URIs, though.

The thinking here is that there are no security/sandbox issues in creating a
result tree, only in serializing it to persistent storage. We tried to
separate the two things. Perhaps we have stretched things too far with the
notion that a URI can be used to refer to a resource (a result tree) that is
not persistent. The thinking is that you can create as many result trees as
you like, using any URI that you like, and the transformation API then gives
you a way to access these (in-memory) result trees using these URIs as a
handle. Security concerns only kick in if you try to serialize the result
tree to persistent disk storage.

> 
>  From the use-cases we encountered so far, linking from the result to 
> non-xslt pages like CSS or js is a very common practice. In fact, 
> relative links in the generated content may point to either generated 
> content or non-generated pages from the server. This kinda 
> demands that 
> the base output uri would be the same site and protocol as 
> the original 
> source document (at least for <?xml-stylesheet?>).

Very good point, I see the difficulty: and off-hand, I don't see an easy
solution. Perhaps the handles that are used to refer to in-memory result
trees in the API should not be URIs at all; but the problem of defining
cross-links between multiple result trees remains. Perhaps we need a new URI
scheme?


> Now take this to a scenario of a site with split 
> responsibilities. Most 
> major sites probably are, and it goes down to simple things as user 
> areas like http://www.junk.net/~whoever/. Having no restrictions on 
> relative URIs in xsl:result-document enables a webauthor of 
> one part of 
> the site to shadow pages done by other entities. One can really go on 
> and find stranger scenarios. But I don't wanna be a bore. Not 
> more than necessary.

I'm not sure I understand this scenario in detail, but I get the general
thrust.
> 
> All I try to point out is that implementations should be able to give 
> constraints to relative URIs as well. These constraints should be 
> permitted to be as tough as "you don't go anywhere but where you are" 
> essentially disabling mutliple output documents in that 
> implementation. 
> An example of less strict rules would be that you must not 
> access parent 
> directories ('..' must not be part of the relative URI) and 
> there must 
> not be a page on the server with the same URI.
> 
> 19.1 could read something like
> "There MAY be implementation-defined restrictions on the form of 
> absolute and relative URI that may be used, but the implementation is 
> not required to enforce any restrictions. Implementations MAY 
> restrict 
> the URI to the *base output URI*, effectively disabling 
> multiple output 
> documents."
> instead of
> "There may be implementation-defined restrictions on the form of 
> absolute URI that may be used, but the implementation is not 
> required to 
> enforce any restrictions. Any legal relative URI must be accepted."

I don't think the WG will have any difficulty allowing the implementation to
impose further restrictions, and I will put this on the agenda as issue 183.

Many thanks for the feedback,

Michael Kay

Received on Monday, 19 May 2003 06:05:47 UTC