xml-dev - Re: Parser Behaviour (serious)

["Frank Boumphrey" <bckman@ix.netcom.com>]

I think that this approach as advocated by Peter is just what we need.

It would be nice if one of the 'standards body' could come up with a
recommendation,  It need not be heavy-weight, just official. IMO, however,
this body will not be W3C as they are too wedded to Schemas, and in my
(personal) opinion will not do any thing to extend the life or usefulness of
DTD's.

I wonder if this is something that OASIS might take on. Alternatively an
ad-hoc WG could be put together from this list.

Frank

----- Original Message -----
From: THOMAS PASSIN <tpassin@idsonline.com>
To: <xml-dev@xml.org>
Sent: Wednesday, April 05, 2000 8:55 AM
Subject: Re: Parser Behaviour (serious)


> Peter Murray-Rust writes:
>
> > At 09:16 AM 4/3/00 -0700, Tim Bray wrote:
> > >At 08:48 AM 4/3/00 +0100, Peter Murray-Rust wrote:
> > >>So my summary is:
> > >> - The experts (on this list) cannot agree precisely what a parser
> > >>should
> > >>and should'nt do with various combinations. these include:
> > >
> > >It is not clear that rules could ever be written.
> >
> > If this is true it spells the death of interoperability for information
> > components such as MathML, SVG and CML (chemical markup language).
> >
> <snip/>
>
> > It matters very much. I and Henry are persuading may people to use CML
as
>
> I completely agree with Peter M-R on this.  If you need an important
feature
> such as entity resolution, your document should be able to say so.  This
is
> NOT the same issue as being able to turn a feature on and off, something
> which has not been settled in this list either.
>
> > *part* of their content. Examples are publishers, patents, safety,
health,
> > materials, pharmaceutical, etc. etc. It is *absolutely essential* that
> > everyone interprets the chemistry in the same way. Otherwise people
could
> die.
> >
>
> <snip/>
>
> > Friends, this is too serious to ignore. We decided after a years' debate
> > that we had to have an API for parsers (SAX). I think we know deep down
we
> > have to something here. It may be a document, it may be a piece of
> > software. The response to SAX was so exciting and encouraging - everyone
> > took it on board. I am absolutely sure that all parser writers want
their
> > parsers to be interoperable. The following expresses my desire:
> >
> > <!DOCTYPE molecule SYSTEM "http://www.xml-cml.org/DTD/v10">
> > <?xdev externalEntityExpansion="mandatory" DTDResolution="optional"?>
> > <molecule name="raniditine bismuth citrate">
> >   &ranitidine;
> >   &bismuth;
> >   &citrate;
> > </molecule>
> >
> > <!-- I am not advertising - I happen to have worked on ranitidine -->
> >
> > P.
>
> Peter's suggested approach here is elegant and simple.  As for Tim B's
> statement about there being too many opinions about too many combinations,
> well, David Megginson has written that SAX only handles 80% of the xml-ish
> things you might like to do.  Let's strive towards agreement on 80% of the
> key possibilities here, and we will accomplish something really
worth-while.
>
> Of course, even if we get a system such as Peter has asked for, older
> parsers will ignore any such directives.  So Peter's pharmaceutical
warnings
> could still get ignored by any given processor.  But still, at least you
> could tell users that they could use a range of processors instead of just
> one.  That would be good.
>
> Regards,
>
> Tom Passin
>
>
>
***************************************************************************
> This is xml-dev, the mailing list for XML developers.
> To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
> List archives are available at http://xml.org/archives/xml-dev/
>
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************