Hi Ajith:
Ajith Ranabahu wrote:
1. Added two new methods
public XmlSchemaElement getElementByName(QName name, boolean deep)
public XmlSchemaType getTypeByName(QName name, boolean deep)
These two methods were added to circumvent the issue of deep search
and also not to break the existing code. The older methods however are
deprecated. This seemed to be the path of least resistance but
suggestions are welcome :)
I am really not a fan of this solution. :(
Here's my thinking. It seems to me that if we intended a single
XmlSchema to only hold locally defined items (elements/types), we would
only need a method like getElementByName(String), where the argument was
the NCName - the namespace could always be assumed to be the namespace
of the schema itself. But in fact the API has a QName argument, which
to me implies that the intent is to enable access to anything to which
the XmlSchema object itself has access... in other words all the
imported elements/types from other namespaces as well. The object model
is meant to map closely to the spec.
If you accept that logic, then it's pretty clear that having
getElementByName(QName) actually only search the local schema without
regard for imports is plain and simply a *bug*. Bugs should be fixed.
We should have a test case for this, etc. And if something like ADB
relies on the broken behavior then that code is *also* buggy and should
be fixed.
So, what I'd like to do is:
* (best solution) Fix the problem with the API, and don't bother
providing an option for "local" searches... why would you want/need such
a thing? (if someone can provide a solid use-case I'm flexible on this)
Fix ADB to use the new code.
* (not as good) Fix the problem with the current API, so
getElementByName(QName) has the correct behavior (incl. searching
imports), and ALSO provide a new getElementByName(QName, boolean) (or
even better, getLocalElementByName(QName)) to enable the "local only"
searching.
Either of these, to my mind, would be better than the current state.
Let's please fix this right, as these APIs are going to be with us a
long time.
Thoughts/comments?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
