The XSDModelResolvers are basically used to resolve inline schemas, so using a namespace import resolvers are not applicable in this case.
In case of XSD, the @schemaLocation is handled by org.apache.ws.commons.schema.XmlSchemaCollection for any path specified in the schemaLocation attribute. I believe, we should be able to impose the namespace resolution mechanism for XmlSchemaCollection by creating a custom implementing for org.apache.ws.commons.schema.resolver.URIResolver. Currently, XSDModelResolver provides a custom implementation for org.apache.ws.commons.schema.resolver.URIResolver to resolve the path relative to the contribution. We might have to modify the code for URIResolver to handle the namespace resolution. The URIResolver is now fixed to handle the namespace import resolution for XSDModelResolver using TUSCANY-3117, committed revision 787566 in 2.x. On Wed, Jun 10, 2009 at 2:27 PM, Ramkumar R <[email protected]> wrote: > On Thu, Jun 4, 2009 at 10:51 PM, Simon Laws <[email protected]>wrote: > >> On Thu, Jun 4, 2009 at 4:55 PM, Raymond Feng <[email protected]> wrote: >> > Here is my understanding of the following statement: >> > >> > 3461 1. from the locations identified by the import statement(s) for the >> > namespace. Locations MUST NOT >> > 3462 be searched recursively in order to locate artifacts (i.e. only a >> > one-level search is performed). >> > >> > Let's say we have 3 contributions: C1, C2 and C3. >> > >> > Case 1: >> > >> > C1: import namespace="http://ns1"; location="C2" >> > C2: export namespace="http://ns1"; >> > C3: export namespace="http://ns1"; >> > >> > To resolve an XML artifact (for example, an XSD type {http://ns1}Type1) >> for >> > C1, we first try C2 (as indicated by the @location). If C2 contains the >> XSD >> > Type {http://ns1}Type1, use it. Otherwise try C1. When C2 is searched, >> only >> > the top-level artifacts within C2 are checked. I think that's the >> behavior >> > we have in ModelResolvers. >> > >> > Case 2: >> > >> > C1: import namespace="http://ns1"; >> > C2: export namespace="http://ns1"; >> > C3: export namespace="http://ns1"; >> > >> > The @location is not present, then C2 and C3 are searched as both of >> them >> > export http://ns1. >> > >> > Thanks, >> > Raymond >> > >> >> Right, I think I basically agree with that. The "one level" rule only >> applies when the location is specified explicitly. Otherwise there is >> no concept of levels and the collection of contributions is considered >> to be a flat structure where all exports can be considered (in some >> implementation specific order) when resolving imports. >> >> A note on >> >> > The @location is not present, then C2 and C3 are searched as both of >> them >> > export http://ns1 >> >> More accurately C2 and C3 will be searched in some order until the >> required artifact is found (or not as the case may be). I don't know >> what order we will search C2 and C3 in. >> >> Simon >> > > The specs recommends the following method for search in such cases: > > 3449 There can be multiple import declarations for a given namespace. Where > > 3450 multiple import declarations are made for the same namespace, all the > locations specified MUST > 3451 be searched in lexical order. > > 3455 If the same artifact is declared in multiple locations, this is not an > error. The first location as > 3456 defined by lexical order is chosen. If no locations are specified no > order exists and the one chosen > 3457 is implementation dependent. > > So, we will have to modify the code to follow the lexical order in such > cases. > > -- > Thanks & Regards, > Ramkumar Ramalingam > -- Thanks & Regards, Ramkumar Ramalingam
