Re: An interoperability problem?

[Norman Walsh <ndw@nwalsh.com>]

/ Normand Montour <n_montour@hotmail.com> was heard to say:
| Norm,
|    in your example, for the second document:
|   <?xml-stylesheet href="a.xsl" type="text/xsl"?>
|   <?oasis-xml-catalog catalog="myCat.xml"?>
|   <?xml-stylesheet href="b.xsl" type="text/xsl"?>
|   <!DOCTYPE doc PUBLIC "x">
|   <doc/>
| I suppose you meant:
|   <?xml-stylesheet href="http://example.com/a.xsl" type="text/xsl"?>
|   <?oasis-xml-catalog catalog="myCat.xml"?>
|   <?xml-stylesheet href="http://example.com/b.xsl" type="text/xsl"?>
|   <!DOCTYPE doc PUBLIC "x">
|   <doc/>

Yes. Sorry cut-and-paste-and-then-change-the-first-one error. :-)

| Nevertheless, is it reasonable to expect to have two processors
| of various "speeds of behaviour" addressing the same resource types
| (in this case XSL)?

I'm not sure what you mean. Before I introduced the catalog PI, I
assert that both of these processors produced exactly the same result
from the same source document. After the PI was inserted, they
produced not only different results, but the greedy processor may have
produced incoherent results.

| Given this unlikely situation, and given that we are
| set to resolve any URI that may exist anywhere in the scope of the
| document, I don't see a problem for us recommending that, for the
| sake of coherence in the resolution of URIs, the PI gets placed immediately
| following the xml PI.

We can recommend it, but if some other spec also recommends it (or if
some future XML Recommendation from the W3C demands it), then this
interoperability problem will arise.

I suppose we could say that the catalog PI will be ignored if it isn't
the first PI, but then catalogs just won't work when some other spec
says its PIs have to come first.

I guess what I'm really saying is that this problem in particular and
another problem[*] I thought of are making me reconsider the value of
the catalog PI.

                                        Be seeing you,
                                          norm

[*] The other problem is one of caching and code-reuse. I admit this
is purely an implementation issue, so I wouldn't propose it alone as
an argument against the PI. But since I've mentioned it, here it is:

It's easy to imagine constructing a single "catalog object" in an
application and reusing it for all parsing. In fact, it's not clear
that existing applications (Saxon, Xalan, etc.) that provide hooks for
setting up an EntityResolver or URIResolver from the command line
offer any opportunity to do otherwise. This seemed fine (although
there is a slightly open issue about what "./catalog" would mean in
the list of initial catalogs in this case), but now that a document
can change the list of catalog files, I'm not sure how to make this
work without constructing a new catalog object for each parse. And I'm
not sure that there are hooks for doing that in current applications.
(I think, for example, that these applications use the same ER and
URIR for all source documents and stylesheets...)

-- 
Norman.Walsh@Sun.COM   | 'Heartless Cynics,' the young men shout, /
XML Standards Engineer | Blind to the world of Fact without; / 'Silly
Technology Dev. Group  | Dreamers,' the old men grin / Deaf to the
Sun Microsystems, Inc. | world of Purpose within.--W. H. Auden