[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Associating DSSSL style sheets with documents
> 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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|