Re: An interoperability problem?

[Norman Walsh <ndw@nwalsh.com>]

/ 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.

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

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.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | If a little knowledge is dangerous, where is
XML Standards Engineer | the man who has so much as to be out of
Technology Dev. Group  | danger?--T. H. Huxley
Sun Microsystems, Inc. |