Re: XInclude vs SAX vs validation
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". 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.  - http://lists.w3.org/Archives/Public/www-xml-linking-comments/2001AprJun/att-0074/01-NOTE-FIXptr-20010425.htm Simon St.Laurent
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format