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 which was 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]
