[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath and XPattern (was Re: More on tamingSAX)

• To: David Megginson <david.megginson@g...>
• Subject: Re: XPath and XPattern (was Re: More on tamingSAX)
• From: Uche Ogbuji <Uche.Ogbuji@f...>
• Date: Thu, 23 Dec 2004 22:18:58 -0700
• Cc: xml-dev@l...
• In-reply-to: <75cb920c041223124846b805a9@m...>
• Organization: Fourthought, Inc.
• References: <E1ChXnb-0004PJ-00@u...> <41CB29FA.8010201@t...> <75cb920c041223124846b805a9@m...>

On Thu, 2004-12-23 at 15:48 -0500, David Megginson wrote:
> On Thu, 23 Dec 2004 22:26:34 +0200, Oleg Tkachenko <oleg@t...> wrote:
> 
> > It would be really nice to have such streamable XPath subset strictly
> > defined (and probably with different name). Many attempts to implement
> > XPath in a streaming way, such as Microsoft's XPathReader [1] (which is
> > actually used in Biztalk internally) are hardly widely usable primarily
> > because of proprietary XPath subsetting.
> 
> This doesn't sound like too bad a job, but it's not worth it unless
> people are willing to use and support it in their code.

I agree.  We need a standard (no, no consortia need apply: the community
can sort this one out themselves, I think).

There is plenty of implementation experience to make it a snappy
process.

But I wonder whether all the various players would really be willing to
get virtually together and do the job.


> Obviously, a
> streaming XPath subset is appropriate for use with streaming parser
> APIs like SAX and STAX -- where else would it be useful?  XML
> networking?  Search and indexing?

Pretty much *everywhere*.  I come up with the need of streamable XPath
subset over and over again.  I think others do as well.


> There's also the question of context -- would the only context be the
> stack, or do people hope to have access to left siblings as well?

I'd say only the parent stack, or shallow but very wide documents become
resource hogs.  An extension mechanism could allow implementations to
support sibling access, or perhaps that would be a matter of conformance
levels (a la DOM or XAPI).


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html
Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-xml.html
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html
Use Universal Feed Parser to tame RSS - http://www.ibm.com/developerworks/xml/library/x-tipufp.html
Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/
The State of Python-XML in 2004 - http://www.xml.com/pub/a/2004/10/13/py-xml.html

• Follow-Ups:
  • Re: XPath and XPattern (was Re: More on tamingSAX)
    • From: Jeff Rafter <lists@j...>
  • Re: XPath and XPattern (was Re: More on tamingSAX)
    • From: Karl Waclawek <karl@w...>

• References:
  • RE: XPath and XPattern (was Re: More on taming SAX)
    • From: "Michael Kay" <mike@s...>
  • Re: XPath and XPattern (was Re: More on tamingSAX)
    • From: Oleg Tkachenko <oleg@t...>
  • Re: XPath and XPattern (was Re: More on taming SAX)
    • From: David Megginson <david.megginson@g...>

• Prev by Date: RE: XPath and XPattern (was Re: More on tamingSAX)
• Next by Date: RE: XPath and XPattern (was Re: More on tamingSAX)
• Previous by thread: Re: XPath and XPattern (was Re: More on taming SAX)
• Next by thread: Re: XPath and XPattern (was Re: More on tamingSAX)
• Index(es):
  • Date
  • Thread