[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ISSUE: 133 Refactor Section 4.
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
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Montag, 11. August 2008 20:01 An: sdo@lists.oasis-open.org Betreff: Re: [sdo] ISSUE: 133 Refactor Section 4. 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"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]