[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: ISSUE 41: Discussion and Proposals
Based on last weeks’s discussion, the proposal is now to
add the following annotation (changes in bold) /* * Copyright(C) OASIS(R) 2005,2010. All Rights Reserved. * OASIS trademark, IPR and other policies apply. */ package
org.oasisopen.sdo.annotations; import
java.lang.annotation.ElementType; import java.lang.annotation.Retention; import
java.lang.annotation.RetentionPolicy; import
java.lang.annotation.Target; @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.PACKAGE) public @interface SdoSchemaOptions {
public enum
XsdForm {QUALIFIED, UNQUALIFIED};
XsdForm
elementFormDefault() default XsdForm.UNQUALIFIED;
XsdForm
attributeFormDefault() default
XsdForm.UNQUALIFIED; } Here is the proposed wording:
If
the @SdoSchemaOptions annotation is present as part of a package information
file, then whenever the classes in this package are passed to any of the
XSDHelper.generate methods, a Java implementation of SDO MUST include the
corresponding attributes on the <schema> element of the generated XSD at
least wherever the form default is “qualified”. [JAV03070501]
If the @SdoSchemaOptions annotation is not present , the SDO
implementation’s MAY include elementFormDefault=”unqualified”
attribute and attributeFormDefault=”unqualified” attributes or MAY
omit these attributes,. [JAV03070503] @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.PACKAGE) public @interface SdoSchemaOptions {
public enum XsdForm {QUALIFIED, UNQUALIFIED};
XsdForm elementFormDefault() default XsdForm.UNQUALIFIED;
XsdForm attributeFormDefault() default
XsdForm.UNQUALIFIED; } _______________________________________________________________________________________________________________ I would like to add the following to the SDO Core Spec.
I’m not so sure about the last line… do we want to use this
property to specify the form, or only the URI? If we go with the proposal
here, we should also change the Java spec (section 3.6.6).
The
xmlPropertyURI controls the namespace of the element or attribute under
which the property value will be serialized. In this way, it is possible
to specify that, in XML, namespace of the property differs from the namespace
of the type (as would occur if the property were defined through an xs:ref
element). By setting this property to be the same as the Type’s
URI, the user can effect that the XML form of the attribute or element is “qualified”.
If the XML URI is left unspecified or set to an empty string, the
property MUST be rendered unqualified. [COR….] When generating
schema containing types where there is a consistent usage of xmlPropertyUri,
such that all attributes or all elements are rendered qualified, implementations
MUST set the attribute- and element- FormDefaults in the <schema> tag.
[COR…] Von: Barack, Ron [mailto:ron.barack@sap.com] Hi
Everyone, In
last week’s discussion I promised to review the 2.1.1 spec, to see if we
could, in good conscience, define the standard behavior when generating schemas
to be to generate a schema with elementFormDefault=”qualified”, or
whether this would constitute a breaking change. The
good news is, I believe we are 100% free when defining the behavior when
generating meta-information from Java interfaces. The 2.1.1 spec deals only
with the generation of static SDOs from an existing XSD, not with the use of
static SDOs as sources of information. On
the other hand, the it is clearly implied that
elementFormDefault=”qualified” is not the default behavior when the
metadata comes through the API. The clearest argument here is
two tables at the beginning of chapter 10. It is also the case that none
of the examples of generated XML use qualified element names other then when
referring to root elements. Furthermore, although chapter 9 defines the
mapping *from* XSD *to* SDO, none of the mapping tables
references elementFormDefault. To me, this more or less ties our
hands when types are defined through the API. This
leaves us with 2 things that we can add: the xmlUri openContentProperty
that can be used when defining properties through the API, and the Java
annotation: I
hope that the Java annotation will not be very controversial: /* * Copyright(C) OASIS(R) 2005,2010. All Rights Reserved. * OASIS trademark, IPR and other policies apply. */ package org.oasisopen.sdo.annotations; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.PACKAGE) public @interface SdoSchemaOptions {
public enum
XsdForm {QUALIFIED, UNQUALIFIED};
XsdForm
elementFormDefault() default XsdForm.QUALIFIED;
XsdForm
attributeFormDefault() default
XsdForm.UNQUALIFIED; } Here is the proposed wording: If
the @SdoSchemaOptions annotation is present as part of a package information
file, then whenever the classes in this package are passed to any of the
XSDHelper.generate methods, a Java implementation of SDO MUST include the
corresponding attributes on the <schema> element of the generated XSD at
least wherever the form default is “qualified”. [JAV03070501]
If the @SdoSchemaOptions annotation is not present , the SDO
implementation’s default behavior MUST be for the <schema> to
include an elementFormDefault=”qualified” attribute and MAY include
an attributeFormDefault=”unqualified” attribute. [JAV03070503] @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.PACKAGE) public @interface
SdoSchemaOptions {
public enum XsdForm {QUALIFIED, UNQUALIFIED};
XsdForm elementFormDefault() default
XsdForm.QUALIFIED;
XsdForm attributeFormDefault() default
XsdForm.UNQUALIFIED; } _______________________________________________________________________________________________________________ I would like to add the following to the SDO Core Spec.
I’m not so sure about the last line… do we want to use this
property to specify the form, or only the URI? If we go with the proposal
here, we should also change the Java spec (section 3.6.6).
The
xmlPropertyURI controls the namespace of the element or attribute under
which the property value will be serialized. In this way, it is possible
to specify that, in XML, namespace of the property differs from the namespace
of the type (as would occur if the property were defined through an xs:ref
element). If the XML URI is left unspecified or set to an empty string,
the property MUST be rendered unqualified. [COR….]. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]