RE: AW: AW: [sdo] ISSUE 133: New proposal

Hi Ron,

 

I think that under this form, point 1 doesn't make any 
sense and should be removed. Point 4 has good wording on the other hand but it 
comes into contradiction with the SDO Java spec that doesn't require inner 
classes, and the sdoj:nestedInterfaces annotation. So the SDO Java spec needs to 
be modified if we agreed to go with inner classes for Schema anonymous types 
(which is fine with me, by the way).

 

Radu

  

  
  From: Bryan Aupperle 
  [mailto:] 
Sent: Tuesday, August 26, 2008 1:13 
  PM
To: 
Subject: Re: AW: AW: [sdo] 
  ISSUE 133: New proposal

  

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: 
   

  
    
    

      "Barack, Ron" 
        <> 
        
08/26/2008 01:25 PM 

      
        
          
          

            
              
To

            <> 
          

            
              
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; 
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:] 
  
Gesendet: Freitag, 22. August 2008 02:20
An: Frank Budinsky; 
  
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:]
Gesendet: 
  Do 21.08.2008 20:35
An: 
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" 
  <> 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:]
> 
  Gesendet: Mittwoch, 20. August 2008 18:23
> An: 
  
> 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" <>
> 08/18/2008 
  10:24 PM
> Please respond to
> "" 
  <>
>
>
> To
> 
  "" <>
> 
  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