[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ISSUE 133: New proposal
Hi Frank, everyone,
One of the extensions in our implementation is that we have introduced an sdoj:JavaName as a way for the user to specify a Java name that is different from the SDO name. We also apply the JaxB algorithm to construct the Java names automatically, which handles problems like the "." character, and also puts things nicely in camelCase, which is what Java users expect, but logically this is equivalent to specifying sdoj:JavaName. I think such behavior will be less surprising than to be changing the SDO name in such cases, especially if there is more than one implementation language involved (each could have ist own rules wrt identifiers). In any case, having sdoj:javaName just seems symmetrical with having sdox:xmlName. It is also consistent with sdoj:JavaClass... I mean, why do we allow renaming of Types/ Classes and not allow renaming of Properties?
But we are currently discussing the Core SDO Spec, the Java-Specific algorithms and annotations should be described in the corresponding chapters of the SDO@Java Spec. And really the issue is what we are going to say about name mangling. The point is, I don't want to be specific that sdo:name is what is used to resolve conflicts and make things complient with the language's requirements. It's only clear that the XSD should be annotated.
For the reasons I gave above, I don't think name mangling (of the SdoName) is warrented because of implementation language requirements. The only real reasons for mangling are dealing with conflicting names in the generated SDO type.
I would really very much prefer that the spec remain silent on the subject of name mangling. It's an allowed way for an implementation to deal with conflicting local names, but that's an implementation detail. But in the spec, we don't have to concern ourselves with such details, but rather with the behavior that an implementation must provide. And I think there is agreement that in case of such conflicts, there is no portable way to address such properties using the SdoName alone...either because the name is not unique or because the spec's not going to tell the user what name is.
Let me make a pass at Radu's points:
_______________________________________________
These principles apply when generating static SDOs from an XSD:
1. The identifiers used in the source code representation of SDO Types and their properties must be unique and non-null.
2. SDO does not specify name any mangling but enables and sometimes requires name overrides though annotations.
3. If the normal generation of source code from an XSD would result in conflicting names, the XSD declaration must contain annotations to override the default name.
4. If an XSD type definition has no name, its name is the same as the next named enclosing declaration. If that results in a conflict, then annotations must be used to override the name.
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.
_________________________________________________
Editorially, I don't think these fit very well in Chapter 9: this is the only place where we would talk about static SDOs and generating static SDOs in chapter 9... If we really want to include this text, we should bring back chapter 4, per my earlier proposal.
Ron
-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Mittwoch, 20. August 2008 18:23
An: sdo@lists.oasis-open.org
Betreff: 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
---------------------------------------------------------------------
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]