From rm at tuxteam.de  Mon Nov 15 12:25:04 2010
From: rm at tuxteam.de (rm at tuxteam.de)
Date: Mon, 15 Nov 2010 13:25:04 +0100
Subject: [xuriella-devel] A few questions about include/import
Message-ID: <20101115122504.GB14713@seid-online.de>

Hello List,

I'm trying to write a small XSLT tracing/debugging tool and stumbled
across some unclear spots.

 - there seem to bee two stacks *xsl-include-stack*  and
   *xsl-import-stack* whose only purpose seems to be cycle detection.
   But shouldn't the starting stylesheeet be on this stack as well?
   
 - The only way to trace import/inclusion seems to be to provide a 
   custom uri-resolver, but such a function has no way to distinguish 
   between being called from import or include. Is there a hidden way
   to detect this?

 - The API for uri-resolver  seems a bit limited. First I'd expect the 
   function to be called with the uri as provided by include/import, but 
   I do get a uri resolved relative to the stylesheet's  base uri.
   Second, wouldn't I be more useful to have a resolver that returns a 
   stylesheet/pathname/rod instead of a uri? That would ease implementation
   of programatically constructed stylesheets or stylesheet caching.


TIA Ralf Mattes




From david at lichteblau.com  Mon Nov 15 13:39:23 2010
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 15 Nov 2010 14:39:23 +0100
Subject: [xuriella-devel] A few questions about include/import
In-Reply-To: <20101115122504.GB14713@seid-online.de>
References: <20101115122504.GB14713@seid-online.de>
Message-ID: <20101115133923.GB26825@radon>

Hi,

very good questions for which I don't have a definitive answer.

Quoting rm at tuxteam.de (rm at tuxteam.de):
> I'm trying to write a small XSLT tracing/debugging tool and stumbled
> across some unclear spots.
> 
>  - there seem to bee two stacks *xsl-include-stack*  and
>    *xsl-import-stack* whose only purpose seems to be cycle detection.
>    But shouldn't the starting stylesheeet be on this stack as well?

It seems to me that the existing mechanism is sufficient to detect
cycles, since a recursive use of the starting stylesheet would still get
detected when it includes itself for the _second_ time, so the infinite
recursion will be prevented in a reasonably timely manner.

>  - The only way to trace import/inclusion seems to be to provide a 
>    custom uri-resolver, but such a function has no way to distinguish 
>    between being called from import or include. Is there a hidden way
>    to detect this?
> 
>  - The API for uri-resolver  seems a bit limited. First I'd expect the 
>    function to be called with the uri as provided by include/import, but 
>    I do get a uri resolved relative to the stylesheet's  base uri.
>    Second, wouldn't I be more useful to have a resolver that returns a 
>    stylesheet/pathname/rod instead of a uri? That would ease implementation
>    of programatically constructed stylesheets or stylesheet caching.

These are use cases I hadn't thought about when writing the code.  Both
cxml and xuriella deal with URIs instead of raw pathnames (and map back
and forth between them), because of the way all XML-related
specification define entity lookups in terms of URIs.

However, I can see that it might be useful to provide a richer API.
Perhaps the uri-resolver should be CLOS object?

(defclass uri-resolver () ())
(deftype situation () '(member :import :include ...))

(defgeneric resolve-relative-uri
    (resolver uri-as-stated-in-document situation)
  => uri, string, or pathname) 

(defgeneric resolve-absolute-uri
    (resolver uri-with-base-uri-merged-in situation)
  => uri, string, or pathname) 

I haven't thought this through entirely though.

Open questions:
  - Perhaps one method is sufficient after all?
  - If a string gets returned, does it designate a uri object or a
    pathname object?
  - Do we need other arguments, like the current base uri?
  - Should be allow streams or strings as return values, or any other
    value suitable as an argument to cxml:parse?  (Probably not, since
    we need to ensure that the newly opened document itself has a base
    URI.)
  - Should we also pass in public IDs, so that this new class can
    replace cxml's entity resolvers, too?

But my instinct is that it might be better to keep the API simple.


d.