On 10/30/07, Glen Daniels <[EMAIL PROTECTED]> wrote: > > 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.
I am agree with your argument about the method signature. And also if I am extending it ByName part can also omited since there is nothing other than the name which can uniquely identify the Element or type. Lets take this senario to explain why ADB needs the parent schema. Lets say we have three elements E1(S1) refers to E2(S2) (in different schema) E2(S2) refers to E3(S3) (in different schema) What currently ADB does is it first find the schema of the E2 (i.e. S2) starting with the S1. (since it should be possible to find it serching through imports and includes starting from S1) Then get the element from the schema and when finding E3 it starts with S2 (previously found parent schema). This is why it needs the parent schema. So you can argue that why E3 can not be found starting with S1 as well? yes this is correct, the only thing it is inefficient since we always have to start search from the bottom. therefore I think it is nice to have getElementByName(String) method as well. Amila. * (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] > > -- Amila Suriarachchi, WSO2 Inc.
