Hi Michael, Thanks for your response. I think there are some differences in how XPath 2.0 expressions are evaluated in "assertions" and "type alternatives".
I am copying some important points from the spec in this regard. Assertions 1) For an element E, there are 0-n assertion declarations. We need to determine validity of the element, E with respect to assertion declarations. 2) E is validated with respect to it's governing element declaration, or the governing type declaration. The element E is validated, but assertions are not checked. 3) A partial PSVI is constructed as per the validation assessment in step 2). At this step, E can be found to be invalid (or, it's validity property is set to notKnown - if the partial validation of E succeeded). 4) From the partial PSVI, determined in step 3), an XDM instance is constructed, whose root node is E. The data model instance only has E itself, it's attributes, children and descendants (but not, siblings, ancestors, or any other part of the input document outside of E). 5) The XPath expression is then evaluated on the constructed XDM instance. This gives us a 'true' or 'false' result. 6) The function signatures in the static context are implementation defined. Type alternatives 1) To evaluate the XPath 2.0 expression in 'test' attribute, the XDM instance is constructed. Infoset (not, PSVI) is constructed by copying E (element information item) and it's attributes, but not it's children. No validation is performed. The root node of the data model tree is E. The ancestors, siblings, children and descendants of E are not represented in the data model. 2) The XPath expression is then evaluated on the constructed XDM instance. This gives us a 'true' or 'false' result. 3) The function signatures in the static context must include, - fn:not function defined in F&O spec. - Constructor functions for all the built in types. In assertions, 'test' attribute is mandatory, whereas, in type alternatives, 'test' is optional. I noticed that current classes for type alternatives, in the latest trunk code of Xerces, do not have implementation of XPath 2.0 evaluation. I think XPath 2.0 evaluation in assertions and type alternatives (as written, above) is quite different, and we need two separate XPath 2.0 processors for these two facilities. Of course, we could abstract the common features in base classes and interfaces. I would work in next few days, on the other supporting classes mentioned by you for assertions (the traverser and representation of assertions in XSModel). For present, I would not work on XPath 2.0 evaluation part, and would plug it later on, as it becomes available. I would get back to the list with some questions, and my work in very near future. On 7/23/08, Michael Glavassevich <[EMAIL PROTECTED]> wrote: > > > Hi Mukul, > > No one has started working on assertions yet. > > For Google Summer of Code, Hiranya is currently working on type alternatives > [1]. Both assertions and type alternatives require support for evaluation of > XPath 2.0 expressions. However, type alternatives only requires a small > subset of XPath 2.0. If there's any overlap with that work it would be > small. > > The XPath 2.0 support in general is a fairly big open issue. Not clear what > Xerces could use for that. I don't think we should try implementing the > whole XPath 2.0 spec in this project. Anyway that still needs to be decided > so would probably be a good idea to start on the other necessary things for > assertion support like the traverser [2] and representation of assertions in > XSModel [3]. > > Thanks. > > [1] > http://www.w3.org/TR/xmlschema11-1/#cTypeAlternative > [2] > https://svn.apache.org/repos/asf/xerces/java/branches/xml-schema-1.1-dev/src/org/apache/xerces/impl/xs/traversers/ > [3] > https://svn.apache.org/repos/asf/xerces/java/branches/xml-schema-1.1-dev/src/org/apache/xerces/xs/ > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [EMAIL PROTECTED] > E-mail: [EMAIL PROTECTED] -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
