sdo message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: AW: AW: [sdo] ISSUE 133: New proposal
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: sdo@lists.oasis-open.org
- Date: Tue, 26 Aug 2008 16:13:03 -0400
If we wanted to be a bit more language
inclusive, we could say something like:
When generating a static SDO in an implementation
language that supports a concept of locally scoped types, such as Java's
inner classes or C++'s nested
classes, then the anonymous type is scoped
to the smallest available enclosing structure.
Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Research Triangle Park, NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com
"Barack, Ron"
<ron.barack@sap.com>
08/26/2008 01:25 PM
|
To
| <sdo@lists.oasis-open.org>
|
cc
|
|
Subject
| AW: AW: [sdo] ISSUE 133: New proposal |
|
Hi Everyone,
Based on today's discussion, here is my wording for these 5 points. As
I said, it's hard to describe the inner class behavior in a language neutral
way, although I certainly support the idea here. Any help clarifying
the wording would be much appreciated.
Ron
____________________________________________
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.
XSD allows for anonymous types to be defined within an enclosing definition.
When generating a static SDO in an implementation languagethat supports
a concept of locally scoped types, such as Java's inner classes, then the
anonymous type is scoped to the smallest available enclosing structure.
For instance, in Java, the anonymous type is by default an inner
class within the class that represents the containing type (see the SDO@Java
specification for details). To achieve global visibility or cross
language consistency when generating static SDOs from an anonymous types,
annotations must be used to specify the name of the static SDO.
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.
____________________________________________________
-----Ursprüngliche Nachricht-----
Von: Barack, Ron
Gesendet: Freitag, 22. August 2008 09:47
An: Barack, Ron; Frank Budinsky; sdo@lists.oasis-open.org
Betreff: AW: AW: [sdo] ISSUE 133: New proposal
Hi,
Actually, regarding point 4, we probably want a solution that is consistant
with what has been decided in the JSR 235 group. That would mean
something like:
4. XSD allows for anonymous types to be defined within an enclosing
definition. When generatic static SDO from an anonymous type, annotations
must be used to specify the name of the static SDO.
And then point 5 allows the implementation to determine the behavior if
the user does not specify the annotation.
Ron
-----Ursprüngliche Nachricht-----
Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Freitag, 22. August 2008 02:20
An: Frank Budinsky; sdo@lists.oasis-open.org
Betreff: AW: AW: [sdo] ISSUE 133: New proposal
Hi Frank,
I only brought up sdoj:javaName to motivate the change I made to the text:
rather than calling out sdoName by name, I refer simply to the need to
annotate the XSD, not to any specific annotation. For the record,
the default javaName is the sdoName, so that if the user only uses the
javaName annotation if he does not want expect to be confused by having
different names, otherwise, he gets the sdoName, as you say. I think,
in general though, Java users expect camelCase. Java programmers
(and automated style checkers!!) expect getCustomerAddress not get_customer_address
or the like, and in such cases getting the Java names to be the SDO name
would be a breaking change.
I'm not so happy to be using aliasName to solve these renaming issues.
This metaproperty was thought of as something that the user sets
(and expect to see exactly the values he put there). It wasn't really
intended as something that the SDO implementation fills up to solve problems
in SDOPath. I think we can get away with mis-using aliasName in some
special cases, because I think very few users are actually using it, anyway,
but we shoulding be saying that anything with a "." or a "_"
in it automatically gets aliasNames.
In any case, this text should be generic enough that we can avoid such
detailed discussions for now, and return to the java name issue once we
get the CD out.
I've been thinking about Radu's comment, that there should be only one
XSD mapping and I realized that the restrictions in the text do not come
from reading in the XSD, the come from the need to generate Java classes
from the Types. In out implementation, which does not attempt to
mangle away name conflicts, the XSD is read and exactly the same types
are defined in both cases. If there are name conflicts, you cannot
generate Java from the types, but the behavior of XSDHelper.define is always
the same. One problem I have with your text is that it really does
require a different type be generated depending on your use case. This
is also a reason why I don't think these "principles", which
basically define the limits when generating source code, should be in the
chapter that says how XSDHelper.define works.
Regarding point 4...what behavior would you suggest? The only possible
alternative is to say that annonymous types must always be annotated. I
could live with this, but I would also like to point out that, in fact,
you never know when a duplicate name might occur, and you never really
reliable know when to annotate. For instance, you could have a type
with an <element ref="tns:bar"> property, but no name conflict.
Only latter, in a different XSD, you could have a type that extends
this type, with an <element name="bar"> property.
Good night.
Ron
________________________________
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Do 21.08.2008 20:35
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] ISSUE 133: New proposal
Hi Ron,
We've also thought that something like sdoj:javaName would be useful. It
makes the most sense if you're defining types that are to be used with
multiple language bindings. Without the ability to customize the names
for
a specific static language, the SDO name needs to be something that will
work for all languages. That said, we also think that things are
definitely simpler for the user if we say that the language names are the
same as the SDO names. Users then only need to keep track of 2 potentially
different names, instead of 3. I think the approach we've been leaning
towards is to keep the XML name as an aliasName and say that the
langauge-compatible name is the SDO name. If you think of it from a Java
programmers point of view, it would be nice if the name passed into
DataObject.get() and the static method names (based on the standard
JavaBean patterns) were the same. The aliasName solves the XML Fidelity
issue.
To summarize, what I'm saying is that I have mixed feelings about the
sdoj:name approach but I think you should open a separate issue if you
want to propose it.
Regarding item #4 below,
> 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.
The problem with this is that we never know if there may be a duplicate
(it may come later), so we can never give it the name of the enclosing
decl. Do you disagree?
Frank.
"Barack, Ron" <ron.barack@sap.com> wrote on 08/21/2008
11:09:55 AM:
> 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
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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]