[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Associating DSSSL style sheets with documents

  • From: lee@s...
  • To: xml-dev@i...
  • Date: Tue, 18 Mar 97 15:24:27 EST

path_info parameter
> 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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.