Re: [sdo] ISSUE: 133 Refactor Section 4.

[Blaise Doughan <blaise.doughan@oracle.com>]

Hello All,

Following up from last weeks call and the discussion points raised by Ron, below is the EclipseLink thinking on SDO-133:

II ISSUE 133: Refactoring the chapter "Generating Java from XMLSchemas" 
http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/200808/msg00003.html

a) Do we want to specify that there is an XSD->Java code generation tool (like xjc in JAXB)
I consider section "4 Generating Java from XML Schemas" sufficient for covering this topic.  Although I think the part starting with "Frequently creation of annotations is done automatically..." can be safely removed.

Also the following paragraphs should be re-worked:

FROM:  "When customizing the default mapping, SDO annotations are added to the schema. This is called an Annotated Schema (AS). The AS is used to generate the Java. The annotated purchase order schema could be called poAS.xsd. The AS is important because all SDO implementations using the same AS would produce the same Java interfaces as defined in the Java code generation section."
TO:    "When customizing the default mapping, SDO annotations are added to the schema. This is called an Annotated Schema (AS). The AS is used to generate the Java. The annotated purchase order schema could be called poAS.xsd. The AS is important because all SDO implementations using the same AS would produce the same Java interfaces (for the annotated sections) as defined in the Java code generation section."

FROM:  "Frequently creation of annotations is done automatically by a code generation tool. In this case the XSLT and AS may be hidden within the implementation of the tool. This is very
convenient in practice because the code generation tool can produce intelligent overrides and customizations in a product-specific fashion without creating any extra files or overhead."
TO:  "Code generators may provide behavior (in a product-specific fashion) equivalent to annotations to automatically solve such problems as naming conflicts."

b) Do we want to specify that such a tool has a compatibility mode, through which users may obtain an XSD that does not require any further name mangling.

We are still considering the following paragraph from section 4.  At the very least we do not consider it necessary to provide an option to accept an AS without further modification.  Our assumption is that an AS would need to be fully annotated and annotated sections are treated as is already.  We would not want to have to differentiate between user annotated schemas, and schemas created through some sort of compliance tool.

"Even though the AS may be hidden within a tool, every tool must provide a compliance
option to produce the AS if requested. Also every tool must provide a compliance option
to accept an AS without further modification as the input for code generation. This
insures that an AS will produce the same Types, Properties, and generated interfaces for
all implementations."

-Blaise

Bryan Aupperle wrote:

OF1176C90F.2CD9B1F6-ON8525749C.004CB5D4-8525749C.004CE1E0@us.ibm.com" type="cite">
Here is a version of the section that could be moved from the Java spec to the core spec.:

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Master Inventor

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php