Hi Mukul,
I stand by what I said before. The namespace bindings for the schema and
F&O namespaces have no special standing. You may potentially need all of
the in-scope namespace at the assert element in order to process the XPath.
If PsychoPath is only made aware of those two namespaces how could it ever
process an XPath like "@my:length eq fn:count
(./a:children/b:grandchildren)" correctly (where "my", "a" and "b" are
bound to other namespaces in the user's schema)? PsychoPath can't know what
those bindings are unless it's explicitly told what they are.
The static context does include all the in-scope namespaces. See section
3.13.6.2 in the spec [1]:
2.2 The static context is given as follows:
...
2.2.2 The statically known namespaces is the {namespace bindings} of X.
2.2.3 The default element/type namespace is the {default namespace} of X..
2.2.4 The default function namespace is
http://www.w3.org/2005/xpath-functions.
...:
where {namespace bindings} is defined [2] as: "A set of Namespace Binding
property records. Each member corresponds to an entry in the [in-scope
namespaces] of the host element, with {prefix} being the [prefix] and
{namespace} the [namespace name]."
This has to be captured from the schema document and communicated to the
XPath processor in order to have a correct implementation. The opportunity
to retrieve the in-scope namespaces is in the traverser. For example:
NamespaceSupport namespaceContext = schemaDoc.fNamespaceSupport;
Enumeration currPrefixes = namespaceContext.getAllPrefixes();
while (currPrefixes.hasMoreElements()) {
String prefix = (String)currPrefixes.nextElement();
String uri = namespaceContext.getURI(prefix);
// Store each prefix mapping on the XSAssert component.);
...
}
Hoping that makes sense.
Thanks.
[1] http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/#sec-xpath-valid
[2] http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/#declare-assertion
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]
Mukul Gandhi <[email protected]> wrote on 11/14/2009 09:47:35 PM:
> Hi Michael,
> Thanks for ideas. Nice ones I believe.
>
> On Sun, Nov 15, 2009 at 12:24 AM, Michael Glavassevich
> <[email protected]> wrote:
> > I'm still scratching my head over how this is implemented, now with
> > specialized methods for getting and setting prefixes for the schema and
F&O
> > namespaces.
>
> :-) I'll try to explain this.
>
> > We shouldn't need to special case them. These namespaces are
> > no more or less special than the user's namespaces and really all
should be
> > pulled from the SchemaNamespaceSupport in the traverser. We should be
able
> > to copy all of the in-scope namespace bindings from the
> > SchemaNamespaceSupport object on to the static context in PsychoPath
and
> > that will include bindings for the schema and F&O namespaces if they
exist.
>
> You have certainly suggested a better design for this particular need.
> But I think, we can retrieve SchemaNamespaceSupport object only from
> the object, XSDocumentInfo. Or is there any other way?
>
> I presently store the XSD and XPath 2 F&O namespace prefixes in the
> object, XSAssertImpl. At first though that didn't look a nice design
> to me, because the object XSAssertImpl is specific to assertions, and
> how could we store a global string, like the XSD prefix and F&O prefix
> in this object, and there is also a bit of redundancy in this design,
> because all XSAssertImpl objects store this particular information
> (i.e, the XSD & F&O prefix).
>
> In the logic that I implemented, I get the XSD and F&O prefix only
> from the 1st XSAssertImpl object in the list. This technique achieves
> our functional requirements, to retrieve XSD and F&O prefixes, that
> need to be set on the PsychoPath dynamic context object.
>
> When I look at this design from another perspective, it also looks
> correct to me. The requirement to store the XSD and F&O prefix into
> XSAssertImpl is special to assertions, and using the object
> XSAssertImpl as a store for this, look correct to me. In fact I chose
> this design, because I couldn't find any other way to access the XSD
> and F&O prefixes (or say, the objects SchemaNamespaceSupport or
> schemaDoc), from within AbstractPsychoPathImpl.java. The objects
> SchemaNamespaceSupport or schemaDoc are available in traversers, and
> seemingly not after that flow (i.e, in the XMLSchemaValidator layer).
>
> I think, it's not right to set all namespace bindings present on the
> <schema> element to the PsychoPath static context. We only need to set
> the XSD and XPath 2 F&O bindings to PsychoPath. To my opinion, setting
> anything else to namespace bindings on PsychoPath static context, from
> the <schema> element is redundancy, and also likely functionally
> wrong.
>
> > Is that what you were ultimately planning to do, with these recent
changes
> > just being an intermediate step to eliminate the hard-coding whichwas
there
> > before?
>
> yes :)
>
> But definetely, I am going to rethink the design for this requirement
> based on your suggestion. As of now, though the logic which I
> implemented seem to achieve the funtional objectives of this use case.
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
