OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Associating DSSSL style sheets with documents

[ Lists Home | Date Index | Thread Index ]
  • From: David Seibert <dseibert@sqwest.bc.ca>
  • To: "'Norbert H. Mikula'" <nmikula@edu.uni-klu.ac.at>
  • Date: Wed, 19 Mar 1997 09:22:49 -0800

We agree.  I am certainly in favor of allowing catalogs, as long as PIs
are also allowed, I just don't want to force people to use them.

As far as parsing time, I agree on the estimate of 2-3 weeks for a
non-validating parser with no catalog or public identifier handling.
However, I think 1 week will not be unreasonable for someone who has
learned to use yacc and lex (or some equivalents), _after_ the grammar
is specified properly.  I am spending about half of my time cleaning up
incorrect productions (fortunately I have Peter Sharpe here to clarify
what content is supposed to be allowed).  When I have time to get it
into readable shape (I'm not using standard yacc and lex, so I should
normalize it), I'll post my corrected grammar to xml-dev.

Regards,

David

----------
From: 	Norbert H. Mikula
Sent: 	Wednesday, March 19, 1997 8:09 AM
To: 	David Seibert
Cc: 	xml-dev@ic.ac.uk
Subject: 	Re: Associating DSSSL style sheets with documents

David Seibert wrote:
> More important: if you want XML to be widely accepted, you don't want
> to enforce complications that aren't necessary for everyone.  Catalogs are
> useful, but they aren't so easy to implement, 

Compared to other problems that I was (am) having, catalogs are 
*straightforward* to implement. All in all it takes you about
three days to implement.

> so a lot of people would
> prefer PIs as a less complicated alternative.  James's suggestion for a PI
> form,
>         <?XML-stylesheet type="text/dsssl" href="foo.dsl"?>
> is concise, has all of the necessary information, and is close to the HTML
> syntax to make the transition easier for HTML authors.  I can't improve on
> that.

Catalogs are very important concepts for other things as well. If
somebody
doesn't want to use catalogs, he doesn't have to. Allowing for catalogs
doesn't really complicate the specs of XML and doesn't make it more
difficult 
to learn it.

> As far as the grad student, I believe we were giving them two weeks to
> write an XML parser.

:-) Assuming that you know the tools and the programming language that
you are using, two or rather three weeks is a fair estimation for a
non-validating
XML processor with no support for catalogs and public identifiers. 

Yet another requirement is that we get a revision of spec with all the
missing productions (mostly S) included and some of the productions
fixed
and/or clearified.

> Finally, let's not die on our own sword here.  The main goal is to have
> XML be widely accepted.  A subgoal of that is to make it relatively
> easy to write an XML parser, but it still has to be worthwhile to
> write that parser in the first place, or we've lost the war.  I'm
> not saying that catalogs are absolutely required for XML to work,
> but I do think we need to look at the big picture, not count lines
> of code, to determine the right answer.

* Strongly Agree *

-- 
Best regards,
Norbert H. Mikula

=====================================================
= SGML, DSSSL, Intra- & Internet, AI, Java 
=====================================================
= mailto:nmikula@edu.uni-klu.ac.at 
= http://www.edu.uni-klu.ac.at/~nmikula
=====================================================



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




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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS