Re: [relax-ng-comment] Re: [relax-ng] Identity constraints

[Rick Jelliffe <ricko@topologi.com>]

Streamability is not a requirement. It is an implementation technique, which
fullfils a requirement. There are two requirements which mandate streaming 
AFAICS:

1) The user needs to detect invalidity as early as possible in the data,
to avoid useless parsing.

2) The user needs to conserve space (or to refrain from creating extra
objects): they don't want to build a full tree.

If 1) is the requirement, there are two approaches:

* Implement Schematron in such a way that the constraints can be 
tested as early as possible. See "Optimizing Time-Performance of
Streaming Schematron" http://www.topologi.com/public/SchematronHeuristic.pdf
as an example. Basically, by looking at the axes used, you can allot
contexts and assertion tests to whether they can be tested at an
element start, at an element end, or when the document is complete.
(For example a test that element <row> must only appear in a <table>
could, all being well, be performed when the start-tag for <row> is found. )

* Write the Schematron schema with the assumption that the 
document tree is being incrementally built: that the the current
element has no following sibling.  The only use tests that
work with that assumption.  For example, you can check 
references (in a body) to metadata (in a head), but not
references between arbitrary points in a document. Or work
with dimished expectations: you can only detect IDREFs to an 
ID on an unexpected element if that element is already visible.

If 2) is the requirement, you just restrict yourself to using upward looking
patterns. So instead of testing "This element can have this child"
you test "This element can have this parent".  The more that an implementation
keeps a stack extended with some other information (previous-sibling[1]
for example) then the more that these could be used.

Of course, these are not the way that Schematron implementations
work now. But they could, if it were required. As long as the plain
text of the assertion was not dependent on the implementation,
it is OK. It merely means that a streamable implementation can detect fewer
constraints.   The only trick is to make sure that a steaming implementation
of Schematron reports back whether it can check an assertion or
not, so that an assertion does not fail just because of the particular
implementation: "unable to validate" rather than "invalid".

So Schematron is streamable, in several senses. 

Cheers
Rick Jelliffe


----- Original Message ----- 
From: "James Clark" <jjc@jclark.com>
To: "John Cowan" <jcowan@reutershealth.com>
Cc: <relax-ng-comment@lists.oasis-open.org>
Sent: Monday, October 07, 2002 9:55 PM
Subject: [relax-ng-comment] Re: [relax-ng] Identity constraints


> 
> 
> > > However, outside the database constituency, there did
> > > seem to be a feeling that something lighter-weight than full XQuery was
> > > needed.  I would summarize the desired level of functionality as a bit
> more
> > > than what's in XML Schema, but with a strong requirement that it must be
> > > streamable.
> >
> > I don't understand how identity constraints can be streamable: you have
> > to see the whole document before you know if the constraint is satisfied
> > or not.
> 
> Streamable in the sense that you don't need to keep the whole document in
> memory.
> 
> There's been quite a lot of work on streamable subsets of XPath, but it's
> quite challenging from an implementation point of view.
> 
> James
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>