[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: An interoperability problem?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC