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