[sdo] [SDO-19]: More Granular XML Schema Generation

[Radu Preotiuc-Pietro <radup@bea.com>]

Steve Brodsky [06/Apr/06 05:31 PM] 
If the locations can be specified in a Map it would be easier for the
user to specify it in a Map instead of a callback:

Map<String, String> generateXSDs(List<Type> types, Map<Type, String>
typesToSchemaLocations);

types - the Types to generate
typesToSchemaLocations - the Type is the key and the SchemaLocation is
the value

returns a Map of generated XSDs:
the key is the SchemaLocation and the value is the generated XSD



Steve Brodsky [06/Apr/06 05:35 PM] 
Changing to resolved assuming that the above comment is correct. The
name of the generate function could be improved.



Omar Halaseh [06/Apr/06 08:04 PM] 
Our developers reviewed the proposed API and they think it does not
address the issue of having relative schema location.

For relative addressing, a Type's schemaLocation differs, depending on
which Type is referring to it.

If the "types" parameter contains types in multiple namespaces, then the
2nd parameter won't be able to do its job. Thats why you need both the
current Type and the Type being referenced to be able to figure out the
relative schema location and whether its an include or an import.



James Taylor [20/Apr/06 02:03 AM] 
We are in support of this addition for 2.1


Steve Brodsky [20/Apr/06 02:06 AM] 
The above proposal only addressed imports but not includes because it
assumed generation of all Types in a URI would appear in one XSD.



Omar Halaseh [27/Apr/06 12:32 AM] 
It does support inludes.

String generate(List types, SchemaLoactionResolver resolver)

public interface SchemaLoactionResolver

{ public String getSchemaLocation(Type sourceType, Type
referencedType); } 

The types in passed 'types' list will be generated in one XSD file. For
types referenced within the types in that list, the
SchemaLoactionResolver will return an import if the sourceType and
referencedType types are in different namespaces, and an include if they
are in the same namespace or no namespace.


Blaise Doughan [01/May/06 04:56 PM] 
This file (XSDHelperGenerate) explains the problems with the current
schema generation API, and how they are addressed by the API proposed by
Omar Halaseh.

Thanks to Denise Mahar (from Oracle) for putting this document together.


Blaise Doughan [20/Jun/06 10:26 PM] 
Added more examples.


Blaise Doughan [29/Jun/06 05:20 PM] 
The old API on XSDHelper could remain and add the new API:

String generate(List types, SchemaLocationResolver resolver);

If the SchemaLocationResolver parameter is null then it would be the
equivalent of calling:

String generate(List types);

I believe this to be an SDO issue and that the use case is expected
since the following API exists on XSDHelper to partially solve the
problem:

String generate(List types, Map namespaceToSchemaLocation);



Ron Barack [04/Aug/06 03:32 PM] 
I'm wondering whether the resolver could be used in some other use
cases, namely during parsing as well as generating XSD.

For instance, we may have a copy of a schema stored locally, and want to
access our local copy rather than the official remote one. Moreover,
some schemas, for instance "http://schemas.xmlsoap.org/wsdl/soap/ ",
import other namespaces without giving any schemaLocation at all. In
such UCs, maybe we want to provide users with the ability to load up the
resolver with namespace to location mappings, and something call
schemaLocationResolver seems like a natural place to do this.

My interest is in avoiding feature creep by trying to kill multiple
birds with the relatively large stone that is being proposed in this
JIRA.

Blaise, do you think the problems are too far apart, or do you thing the
schemaLocationResolver can be reused in this way?



Blaise Doughan [19/Sep/06 07:51 PM] 
This is a feature that we (Oracle) would still like to see in the SDO
specification, but we are willing to drop this as a requirement for
version 2.1 and add it to the list of features being considered for
version 3.0.



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

XSDHelperGenerate.doc

XSDHelperGeneratev2.doc