Lists Home |
Date Index |
- From: Peter@ursus.demon.co.uk (Peter Murray-Rust)
- To: email@example.com
- Date: Wed, 07 May 1997 16:19:13 GMT
In message <199705071512.LAA12189@nathaniel.ebt> firstname.lastname@example.org (Gavin Nicol) writes:
> >Norbert's answers agree with what I got and also with the consensus
> >of the group. It's clear that WF files can give *different* data from
> >those with some or all of the ELEMENT declarations. I do not find the
> >behaviour intuitive and believe we have to address it in some manner.
> Agreed. I believe that RE delenda est solves the problems.
I am not sure that I was on board for this discussion (I have been told
that whitespace occupied a large amount of bytes last year :-) A summary
could be useful - it clearly has a good pedigree. Is it a language or an
> >I am sympathetic to trashing the whitespace PCDATA elements, but there is
> >no clear idea of how.
> The SGML rules are not always intuitive either....
> >There has rightly been concern about the conformance of parsers (esp. their
> >reaction to errors). This is an area where I suspect conformance is
> Validation of parsers should *certainly* extend to grove construction
> as well as error handling.
Yes. For those not on the WG, Jon has informed us that the likely major
implementors are keen on conformance , so this must surely be an early issue.
It suggests that we shall need some test data and while this already exists
(torture) I am not sure that the outputs have been rigorously investigated.
Of course there is more than one type of output, and when I compare NXP's
output to Lark's I am comparing an Esis stream to a tree of Elements
(but not a complete grove).
The discussion here and elsewhere makes it very clear that the *parser*
is a fundamental unit and that wherever possible it should be
self-contained and independent of the 'application'. That makes it even more
important for us to specify an API.
Please correct this, but I see three possible outputs from a parser:
- a grove
- an esis_stream
- a tree of elements, possibly with PIs, attached to nodes.
We ought to be able to give outputs for each of these so that implementers
What concerns me at present is that some of the functions (e.g. XML-SPACE)
may vary with parsers and that this could be extremely difficult to pin
down in a monolithic application. I'd recommend that what ever of the
methods above is used, it should be possible to tap into them.
It's also clear that applications must recognise certain *attributes*. At
present these seem to be:
Because most of these are non-trivial (e.g. XML-SPACE extends to its
children, so they have to be stamped with it, but when editing a tree
the attribute may need to disappear from relocated children). XML-LINK
is quite complex and affects content of elements (XML-LINK="EXTENDED").
Is there a case for, and is it possible to have, a PRE-application module
that deals with attributes and other generic stuff. This would also
help people to converge on a single interpretation. I's feel much happier
about telling a pre-application with carefully argued semantics what to
do with whitespace or link structure validation than trusting to any old
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)