Re: XInclude vs SAX vs validation

["Simon St.Laurent" <simonstl@simonstl.com>]

On 21 Aug 2001 21:39:23 -0400, Daniel Veillard wrote:
>   You can implement XPath on top of SAX.
>   You cannot in general, though in a number of case that could be detected 
> and handled specifically have an XPath module working in streaming mode.
> 
>   You are violently mixing the concept of the API and the streamability
> (i.e. being able to operate with a only a small subset of the global
> information set).
>   I inplement my XPath implementation on top of a low level SAX parser
> (well kindof SAX because SAX does not exist for C).
...
>   Of course it is possible, but doing it in a streaming mode is not
> possible generally.

These statements (above and below the ellipsis) do not appear to go
together.  I find that the statement below the ellipsis corresponds far
more closely to my experience.

> > > > Sadly, claims like this have a direct impact on the kind of XPointer
> > > > spec we're like to see emerge from the W3C.  The nature of that spec is
> > >      Hum I'm not sure I understand fully this sentence.
> > 
> > You keep repeating that XPointer is easy, while many others (think
> 
>   Easy to implement on top of XPath.

Which, as several folks have noted, is neither always available nor
always appropriate.

> > FIXptr) have said repeatedly that XPointer is hard.  Your claims, I'd
> 
>   FIXptr allows only those paths IIRC:
>      - 1/2/3/4  : well you may like this pointing language, I don't
>      - id[/2/3] : highly unreliable because it requires a DTD + a parser
>                   in validating mode (and DTD may not be available)

As a foundation, as a 1.0 on which other stuff could be _added_, it
makes far more sense to a lot of people.  Not, apparently, to the XLink
WG.

>   Sure you can make this stream, do you expect it to be reliable
> and user friendly ? If the producer adds a simple comment in the tree
> everything breaks, you don't have named nodes (and if you expect to add
> them don't forget the namespace).

Adds a comment?  I thought child sequences referred only to "element
information items".[1]  Named nodes don't make any difference in this
context either. 

>   FIXptr seems targetted at volatile resources, not for documents expected
> to be pointed at over yers, edited, updated, etc ...

FIXptr seems to be targeted at getting hypertext out the door at a low
cost in processing and learning resources.

>   Yes hard problems usually need non-trivial solutions.

Not all problems are hard.  I seem to remember similar protests when XML
was created from SGML.  Those of us with simpler problems will have a
hard time appreciating the cost/benefit ratio of XPointer.

> > suggest, have soothed the working group into releasing a spec that many
> > of the rest of us find wildly excessive, especially for a 1.0.
> 
>    Woah, you find someone you can accuse, do you feel better now ?
> First, I was far from being the most radical, second you will have to
> find another culprit, I'm not playing that game anymore.

Accuse?  I don't think that qualifies as an accusation.  I simply find
the claim that "implementing XPointer is easy" to be doubtful at best
and its practical impact distressing. 

It's reasonably obvious that you disagree.

[1] -
http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001AprJun/att-0074/01-NOTE-FIXptr-20010425.htm

Simon St.Laurent