[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-dev
Subject:    Re: [xml-dev] XPath and XPattern (was Re: [xml-dev] More on taming SAX)
From:       Alan Gutierrez <alan-xml-dev () engrm ! com>
Date:       2004-12-28 0:56:33
Message-ID: 20041228005633.GF615 () maribor ! izzy ! net
[Download RAW message or body]

* Uche Ogbuji <uche.ogbuji@fourthought.com> [2004-12-27 19:34]:
> Alan Gutierrez wrote:
> 
> >* Jeff Rafter <lists@jeffrafter.com> [2004-12-27 14:40]:

> >>>> Say the test was /foo/bar/[baz2="test"]/baz1

> >>>> <foo>
> >>>>   <bar>
> >>>>     <baz1/>
> >>>>     <baz2>test</baz2>
> >>>>     <baz3/>
> >>>>   </bar>
> >>>> </foo>

> >>>> If your schema stated that the children were (baz1,baz2,baz3)
> >>>> wouldn't you have enough information to know to surrender when
> >>>> you reached baz3?

> >>Unfortunately that solution doesn't win much against the DOM or other 
> >>tree based models.
    
    [snip]

> >   Or, to simply the implementation, a valid document could be a
> >   requirement, which is what I was imagining.

> Ah.  The pipelining approach.  Perfectly sensible.  Luckily most schema 
> languages support validation via streaming API (Schematron is a bit of a 
> problem, unless its query sublanguages are themselves restricted to our 
> XPattern), so we don't run into the awkward problem that we have to tree 
> up a document earlier in the pipeline for validation.

    I like pipelining.

> But I'd say for a first pass at XPattern we leave out Schema aids and 
> maybe they could be a subject of a later "level", as long as one could 
> work in ecumenical schema language support.

    I was thinking of implementing the above, the predicate matching
    engine that would work on streams, and using something gnarly,
    like a specification in an attribute, uh, somewhere.

    In my library, I might say:

    new SipStrategy("/foo/bar/[baz2='test']/baz", "/foo/bar/baz3");

    (Which would test for the pattern, until the second pattern was
        met. If the first pattern matches, events are forwarded, the
        second is met, events are dumped, further events ignored,
        until this strategy concludes.)

    Which would get work going on an engine that matched against a
    stream instead of a tree. If there is one already, let me know.

--
Alan Gutierrez - alan@engrm.com

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>


[prev in list] [next in list] [prev in thread] [next in thread]