[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XInclude vs SAX vs validation
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 21 Aug 2001 21:55:34 -0400
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
> > 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
> 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". Named nodes don't make any difference in this
> 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.