Associating DSSSL style sheets with documents

[lee at sq.com]

> Hmm. How much is "all that code"? I got 1443 lines of code for a catalog
> parser in C++, including comments. 

Remember our dirty perl hacker and the graduate student who is supposed
to be able to write an XMLparser in a week?  That was a big goal initially.

> >Our experience with conneting Panorama with a wide range of databases has
> >been that we needed to do this.  Maybe if all the databases had been
> >built by Gavin :-) we'd have been able to stick with Catalogs, and we'd
> >always have known where to look for catalog even with URLs like
> >    http://www.xxx.zzz/bin/get-doc/40197&user=z305&pass=df4ec5c9&d=113&f=7
> >where d=113 is the document chunk ID, get-doc is the program, 40197 is a
> >PATH_INFO parameter used for versioning, and the URL for CATALOG is 
> >    http://www.xxx.zzz/bin/get-doc/40197&user=z305&pass=df4ec5c9&d=491&f=7
> >and no, I'm not making this up (except I've changed the field names from
> >those used in any one particular currently shipping commercial system).
> 
> Hmm. Looks very much like Astoria to me.
No, actually.

> >Panorama's default algorithm would look for
> >    http://www.xxx.zzz/bin/get-doc/catalog
> >which obviously won't work in this case.
> 
> Depends on how smart get-doc is.

Suppose it's written in C and hard-linked into the web server.
Suppose it was supplied by a commercial vendor, and changing or replacing
it invalidates the support contract for a $500,000 installation...

> >So we need to say where to find the CATALOG file so we can find where to
> >find the DTD.  Or, we put an explicit URL to the DTD.  There's somewhere
> >to do that in SGML, but not for a style sheet or a navspec/table of contents
> >definition file, nor any other ancilliary non-SGML files.  So we use
> >processing instructions in those cases where it's necessary.
> 
> If you can do it using PI's, you can do it using catalogs.

I don't believe this dogma :-)

> The only real points in favor of PI's are:
> 
>   1) It does simplify clients *a little* (no need for catalog parsing, 
>      though resolution is still required).
>   2) They're simpler to hack into a server.
> 
> neither of which carries much technical weight.

I don't care.   If it's the difference between
"our integration team can do this"
and
"our product development or serious programming team could do this"
it's the difference between succeed and fail.

So allow both, OK?  Are you really so set against PIs here?
Is there a (non-religious) reason?

They could be significant comments if you prefer --
<!--*@stylesheet: http://.......@*-->
like httpd server side includes/execs...  (ugh)

Lee



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)