[
Lists Home |
Date Index |
Thread Index
]
* 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
|
