[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sdo] ISSUE 133: New proposal
As we discussed in yesterday's TC call, SAP and IBM (at least, but maybe others) would like to relax the duplicate names requirement somewhat. Here's a modified version of Radu's proposed section 7.2.2 that hopefully will be acceptable to everybody. Frank. 7.2.2 XSD, SDO, and Source Code Names In most cases, the names in XSD, SDO, and the source code are identical. Some XSD constructs, however, produce conflicting names (duplicates) in SDO or names which are not legal identifiers in some implementation languages (for example, names with "." characters). If static SDO is required, all SDO Type names in a URI and all Property names in Type.getProperties() must be unique and must be valid identifiers in the desired implementation language(s). Annotations (sdo:name) in the XSD can be used to change names when necessary. If a Type or Property is renamed, it may in some cases be desirable to also provide access to the original name using an aliasName. For example, to support a static Java implementation class, a name such as "a.b" must be changed to a legal Java identifier (for example, "a_b"). To provide good XML fidelity, the original name may still be provided as an aliasName so that calls to DataObject.get("a.b") would also be supported. If there are duplicates within a set of names and aliasNames (for example, Properties of a Type), the first one will take precedence. In situations such as duplicate names where annotations are not provided by the user, implementations may provide behavior (in a product-specific fashion) equivalent to annotations to automatically change names if necessary. SDO does not specify any specific name mangling algorithm. If predictable, implementation independent, names are desired, an annotated schema (AS) must be used. Implementations which provide automatic mangling, may optionally also provide a means to generate an AS which could be used to ensure portability of its Types and Properties (and generated code) to other implementations. "Radu Preotiuc-Pietro" <radu.preotiuc-pietro@ORACLE.COM> 08/18/2008 10:24 PM Please respond to "radu.preotiuc-pietro@oracle.com" <radu.preotiuc-pietro@ORACLE.COM> To "sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org> cc Subject [sdo] ISSUE 133: New proposal Hello everyone, As discussed in last week's call, I put together a simple proposal regarding moving some of the text from the SDO 2.1.1's chapter 4 to chapter 9. Proposal: Insert a new section in chapter 9, 9.2.2 (7.2.2 in the SDO 3 draft): 7.2.2 XSD, SDO, and Source Code Names In most cases, the names in XSD, SDO, and the source code are identical. When they are not identical, an annotated XSD declares the SDO names. The names in SDO and the implementation language are identical. The following are the naming rules. 1. All SDO Type names in a URI and all Property names in Type.getProperties() must be unique and non-null. 2. SDO does not specify name any mangling but enables and sometimes requires name overrides with sdo:name 3. If an XSD declaration would result in a duplicate name, sdo:name must be specified in the XSD file. 4. If an XSD type definition has no name, its name is the same as the next named enclosing declaration. If that is a duplicate then sdo:name must be used. 5. Implementations may provide behavior (in a product-specific fashion) equivalent to annotations to automatically solve such problems as duplicate names. This is logically equivalent to the implementation creating an Annotated Schema (AS) and then creating SDO metadata from the Annotated Schema. An implementation that provides this behavior should also provide a means to generate the AS. The generated AS should be annotated so that another implementation can define SDO Types and Properties from the generated schema without further name mangling. Having such an annotated schema ensures portability of Types and Properties (and generated code) across all implementations. Thanks, Radu --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]