AW: [sdo] ISSUE 133: New proposal

["Barack, Ron" <ron.barack@sap.com>]

Hi Radu,

As I read the proposal, it requires duplicate name conflicts to be resolved either explicitly through an override with sdo:name, or implicitly, through name mangling, which can be seen as the automated injection of an sdo:name annotation.  It also seems to apply to both code generation and "runtime" definition of SDO Types from XSD.

In effect, we are taking some text that applies (in SDO 2.1) to code generation and saying that it also applies to handling XSDs in general.  In this way, it makes discussions such as the on-going discussion on XML fidelity issues moot.  The name conflicts that Frank's proposals try to handle are now illegal, as far as SDO is concerned, there are no name conflicts.  Users must address the properties through their SDO names.

Is this the intent of the proposal?  If so, we at SAP strongly disagree.  While name mangling is an appropriate behavior for code generation, the approach has, in our view, severe limitations when used at runtime.

1.  Name mangling algorithms are inherently brittle.  The more readable and user friendly the mangled name is, the higher the probability that we will be creating conflicts between the mangled name and some other property... See point 3

2.  Achieving any sort of portability means specifying a name mangling algorithm.  Specifying a name mangling algorithm means breaking running code.

3.  Mangled names are not as user friendly as other approaches to handling naming conflicts.  Frank's proposals, especially since they are so Xpath like, are easier to explain, especially to XML savy users.

Best Regards,
Ron


-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radu.preotiuc-pietro@ORACLE.COM] 
Gesendet: Dienstag, 19. August 2008 04:25
An: sdo@lists.oasis-open.org
Betreff: [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