Re: An interoperability problem?

[Lauren Wood <lauren@softquad.com>]

On 15 May 2001, Norman Walsh wrote:

> / Lauren Wood <lauren@softquad.com> was heard to say:
> | > Now, the greedy processor is going to retrieve these stylesheets:
> | > 
> | >   http://example.com/a.xsl
> | >   file:///stylesheets/bPrime.xsl
> | > 
> | > But the lazy processor is going to retrieve:
> | > 
> | >   file:///stylesheets/aPrime.xsl
> | >   file:///stylesheets/bPrime.xsl
> | 
> | Why? The lazy processor should also be storing the catalog PI, 
> | and should keep the document order, and then take that order into 
> | account when processing the items that are affected by the 
> | presence of the catalog PI. So in this scenario, I'd say the lazy 
> | processor (which threw away, or didn't make use of, relevant 
> | information) is the incorrect processor.
> 
> It's not that simple. In order to be useful, the catalog PI has to be
> processed as it's encountered (that's how the doctype entity will be
> found, for example). And a resolver library might naturally do that.
> I think the resolver library might also legitimately "consume" the
> catalog PIs and not pass them on to the application.

True.

> But the resolver library won't know anything about the stylesheet (or
> other) PIs, so it can't do anything about them.

Also true. Yes, this is yuck.

> I suppose it would be possible to restore the catalog path to some
> default state after the parse and then re-apply those PIs as the
> document was evaluated, but that strikes me as a *lot* of complexity
> for every application that's interested in providing catalog support.

Maybe we do need to say this is an error/don't do this/check your 
documents.


Lauren