Hi Blaise, everyone,
I would argue to remove the chapter entirely. I
don't see a need to specify an XSD -> Static SDO tool as part of the SDO
spec. In one way, I think it's somehow out-of-scope for us... not in the
sense of not fitting within the TCs charter, but in the sense that the rest of
the spec concerns itself with a runtime library, only this one chapter defines
a design time functionality. Also, I think why XSD -> Java, why not
Java -> XSD? Why not RDB schema -> Java? Why not the XML
representation of the {commonj.sdo}Type -> Java? It's true I expect
most SDO implementation to come with reasonable tool support, including
converting from XSD to static SDO. I don't see the
need to specify the tool landscape, this should be one of the things that
differenciates our products.
In the chapter as it stands, especially in the section
that you find sufficient, I don't see a single statement that's normative or
testable. What is this code generator? Is it an eclipse plugin, is
it an operating system command, is it an ant script?
In my opinion, we can live without this
chapter.
Ron
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