Re: XInclude vs SAX vs validation

[Daniel Veillard <veillard@redhat.com>]

On Tue, Aug 21, 2001 at 08:08:39PM -0400, Simon St.Laurent wrote:
> On 21 Aug 2001 18:35:27 -0400, Daniel Veillard wrote:
> >  when starting from an XPath implementation, it's not. I really built
> > my implementation in 2 weeks on top of my XPath toolkit and at that
> > time I was still discovering XPath itself.
> 
> Many of us don't work in environments where XPath is available (SAX) and

  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).

> >  What I want to point out is that it's a question of reusing previous layers
> > to build the next generation tools. That's what makes tools more powerful
> > and better in the end.
> 
> If those layers are present.  Not everyone shares the same set of
> layers, and developing layers with dependencies on lower layers which
> don't fit common constraints isn't especially friendly to those of us
> attempting to implement hypertext with a different tool kit and set of
> priorities.

  Sure, implementing a high level functionality is harder if you limit
yourself to only a very specific way of accessing your data. Who's fault
its it ? 

> I don't grasp what you're saying here.  Mixing assembler and C and even
> Java isn't that difficult. Supporting all of XPath in a SAX framework
> seems largely impossible.

  Of course it is possible, but doing it in a streaming mode is not
possible generally.

> > > 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.

> 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)

  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).
  FIXptr seems targetted at volatile resources, not for documents expected
to be pointed at over yers, edited, updated, etc ...

  Yes hard problems usually need non-trivial solutions.

> 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.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/