Fw: XRI requirements - for those whose are interested in XPath and SchemaIdentity constraints

[Eric Ye <er...@locus.apache.org>]

Jeff meant to send this to the mailing list.

----- Original Message -----
From: "Jeffrey Rodriguez" <je...@hotmail.com>
To: <er...@locus.apache.org>
Sent: Wednesday, July 12, 2000 1:28 PM
Subject: Re: XRI requirements - for those whose are interested in XPath and
SchemaIdentity constraints


> Hi Eric,
>
> Thanks for your observations, I agree that we don't want or need to cache
> the whole instance document in memory to support identity-constraints.
>
> Typical use of key and keyref can be accommodated with some
> caching structure. That is not a problem, for example: You had
> have to do this in applications that use  streaming parsers if
> you want to have random access to the information parsed.
>
> What, I was trying to  point out is that according to the Schema
> structures spec all variety of identity-constraint definitions use
> XPath expressions ( section 2.2.4 of structures).
>
> So at the bare minimum, we agree, that we need to be able to process
> XPath expressions.
>
> To support XPath expression then we need to be able to use the
> XPath syntax( which is not that complex). An existing XPath processor
could
> be used or an API could be written that would parse an XPath expression.
>
> The next step would be to bind the XPath expression to a data model.
>
> XPath models an XML document as a tree of nodes.
>
> This is why it is natural that many implementation would use
> the DOM.
>
> My point is that a  "full" DOM maybe is too expensive to just support
> XPath expression in Schema.
>
> So what are the alternatives:
>
> 1) To model the tree of nodes internally through some lighter
>    structure, and to do our own parsing of XPath expressions. This
>    would be some internal ad-hoc API for Schema.
>
> 2) To have a lighter version of an XPath processor which would do
>    similar thing than 1) following some standard API ( Standard in the
>    sense that if we support XPath as part of the Xerces core then
>    this light version would use the same API). The difference with a
>    standard XPath implementation  would be that this implementation
>    would be "light" and would not support reverse axis and other
>    XPath features not needed for Schema ( yes, I know this is also an
>    ad-hoc implementation).
>
>
>
> In your database analogy, you may have meant a tree node,
> since that is the model that XPath follows.
>
> >associated with one row in a database table. The validator only needs to
> >cache a very small tree every time it encouters "a row in the database
> >
> >table" when reading XML instance document, (and then trash it, I know
there
> >are some implications here if we don't do garbage collection, but
continue
> >reading, caching seems inevitable). Even if the whole document is just
> >
>
> Yes, the details about internal memory management is something that we
need
> to think.
>
> Creating and  releasing  too many "small trees" have performance
> implications.
> Yes there is always a trade off between memory and performance.
>
> My approach would be to cache a "reasonable" amount of small trees, in
> some internal table structure.
>
>
> >record in a datable table, then whole tree won't be big enough to be a
> >performance burden. Also optimization can be done to minimize the
footrpint
> >of the tree and get tree traversal very fast.
> >
>
> Do you mean memory instead of performance?
>
>
> >Even if it's only forward axis and stream parsing, the validator still
need
> >to cache the path (or partialy?) from the context element node to the
> >matched(or selected) element or attribute, it is kind of like traversing
a
>
> Yes, of course.
>
> >branch of the tree, if it matchs, throw it away. The really nasty thing
in
> >the Schema Identity constraints is that it allows you to have multiple
> >fields(every field need a path of itself), and a context element could
>
> A little of background on identity-constraints so readers are not
> confused.
>
> Every schema identiy-constraint component has as content among other
> things an XPath selector and one or more fields.
> The Selector specifies an XPath expression relative to instances
> of the element being declared.
> A Selector declaration is associate with one or more fields.
> A field specifies XPath expressions relative to each element
> selected by a selector. This must identify a single node (element
> or attribute) whose content or value, which must be of simple type,
> is used as a constraint. This single node need not necessarily be
> within the selected element.
>
> For an example look at  Schema primer section 5.1, the report.xsd
> example.
>
>
> >typically have one key and one keyref defined, so the validator could end
> >up
> >with caching multiple branches of the same tree, some of them are
> >overlapping.  Whereas, with ONE cached tree for the context element, all
> >key, keyrefs and their fields can be caculated by using that one tree.
In
> >addition, the solution given above will only provide a subset of what
> >Schema
> >spec specified, another downside is that it probably won't be a
> >straightforward  implementation.
> >
>
> Yes, this is a difficult problem.
>
>
> > > So the architecture should allow a pluggable XPath component through
> > > an interface.
> > >
> >Agreed.
>
> I thing this is in accordance to the component pluggability requirements
for
> the new architecture.
> Great.
>
> >
> >Jeff, I know, my office is almost right across yours :-), but just want
to
> >throw in my 2 cents on the mailing list.
> >
>
> Your 2 cents is a million $ to all of us, and in the spirit of
> open discussions, I hope other readers of the list will contribute
> with their ideas on this topic about XPath, and Schema/XPath.
>
>
>
>
> Thanks,
>                  Jeffrey Rodriguez
>                  IBM Silicon Valley
>
>
>
>
>
>
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>