Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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".[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 
|
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
|
|||||||||
