Re: [sdo] ISSUE 133: New proposal

[Frank Budinsky <frankb@ca.ibm.com>]

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