OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues


Hi Blaise,
 
But we're starting from an XSD that defines two declared properties, that are differenciated exactly by their namespace uri.  If we SHOULD NOT use the namespace uri to differenciate them, what SHOULD we use?
 
I'd be really against any proposal that required the namespace-uri() to be specified even if there are no duplicate properties.  This would be a breaking change for every <element ref="> property, and be adding a lot of complexity to handle something that is a relative corner case.
 
Let me see if I understand the use case for the getURI() method - you have the property in your hand, must you want to find out how to address it using SDOPath.  Is that right?
 
I'm not so clear whether you are arguing for the getURI() method or against the proposal in general.  Let me ask you this way, if we added the getURI() method, would Frank's proposal be acceptable to you?
 
Ron
 


Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Montag, 11. August 2008 22:21
An: sdo@lists.oasis-open.org
Betreff: Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues

Hi Ron,

The basic point I'm trying to make is that a types's declared properties are not namespace aware, so a namespace uri SHOULD NOT be used to differentiate the properties. 

In my interpretation of the proposal asking each of the properties for its name would return "bar".  My concern is that there is currently no means available to someone using SDO metadata to indicate that the String supplied to the get method should be namespace qualified (they need to have knowledge of the XML schema).  This is the reason I suggested having the getURI() method.

Another possible interpretation of the proposal is that asking the names of each of the properties would return "bar" and "bar[namespace-uri()='http://the-tns2-namespace']".  This eliminates the above concern, but we could also apply other name mangling algorithms which would be more compatible with code generation.

-Blaise

Barack, Ron wrote:
9279AFBA5302884AB7169C4C51B6FDF70A9A65@dewdfe1a.wdf.sap.corp type="cite">
Hi Blaise,
 
I'm not sure I follow your logic for option 1.   Are you saying that if we allow the "namespace-uri()" notation, that it will then be required to address any element, whether a conflict is there or not?  Why couldn't we just say that if namespace-uri() is not specified, we return the first element whose local name matches.  It might not be so helpful when there are duplicates, but at least it provides reasonable and backwards compatible behavior when there are no duplicate names.
 
@Frank:  suppose the order of the 2 "bar" elements were reverse.  How would you then address the second element?
 
Regarding the Property.getURI() API, can you give a use-case why this is necessary?  Also, do you think Property is the right place for the method, or do you think it belongs to XSDHelper (eg, XSDHelper.getURI(Property p))?  The question basically boils down to, is this another of the wierd use-cases we are forced to handle because we want better XML fidelity, or is this a reasonable piece of metadata, that could be valid for other sources of metadata, such as RDB schemas, or interface introspection...  If it's valid for other sources of metadata, then we should definitely add not only Property.getURI(), but we should also add the field to {commonj.sdo}Property, right?
 
Thanks for your efforts,
Ron

________________________________

Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Mo 11.08.2008 17:50
An: sdo@lists.oasis-open.org
Betreff: Re: AW: [sdo] Update of remaining XML Fidelity duplicate names issues



Hi Frank,

For SDO-67, I am not against a namespace aware API.  In fact one is
necessary for properly querying open content properties (which have a
namespace URI).  We can either use the one you proposed based on XPath,
or the one I proposed based on the javax.xml.xpath APIs for handling XPaths.

The aspect of the proposal I object to is the use of namespace URIs to
differentiate a Types declared properties.   The declared properties of
a type are not namespace aware (there is no Property.getURI() method),
so how could this be used as a differentiator?  As I see it we have the
following options:

1.  Make declared properties namespace aware.  This would mean the
following calls would be valid (based on your example schema fragment):
    dataObject.get("bar[namespace-uri()='http://the-tns2-namespace' <http://the-tns2-namespace'/> ]");
   
dataObject.get("bar[namespace-uri()='http://the-target-namespace' <http://the-target-namespace'/> ]"); 
// Assuming that elementFormDefault="qualified"
    Property property =
dataObject.getType().getProperty("bar[namespace-uri()='http://the-tns2-namespace' <http://the-tns2-namespace'/> ]");
    property.getURI();  // NEW METHOD - would return
"http://the-tns2-namespace <http://the-tns2-namespace/> "
    dataObject.get("bar");  // Would return null as there is no property
with name="bar" and uri=null.

2.  Keep declared properties namespace unaware.  This would mean that
one of the properties would require an annotation to change the name.


-Blaise

Barack, Ron wrote:
  
Hi Frank

I like these proposals.  Two comments, additions.

First, I would like to go through the document and take out all text stating that name conflicts must be resolved by annotating with sdo:name.  We are now allowing duplicate SDO names, and specifying the behavior.

Second, when dealing with name conflicts, I would rather avoid explicitly requiring name mangling.  I would rather say that the e.g., attribute names must never hide element names.  This is the behavior that is interesting for the user.  Name mangling is an implementation detail in order to achieve this.  Your wording for proposal 3 is actually already what I have in mind, and I would like similar wording in proposal 2.


Ron

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com]
Gesendet: Freitag, 8. August 2008 22:02
An: sdo@lists.oasis-open.org
Betreff: [sdo] Update of remaining XML Fidelity duplicate names issues

Hi Guys,

I've updated the 4 remaining unresolved duplicate name proposals, to
reflect the discussions/feedback so far.

The remaining issues are (see also section 2.1 in
http://www.oasis-open.org/committees/download.php/26722/SDO_XML_Issues.doc
):

1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4)
2. SDO-71 SDOPath handling of '@' character (section 2.1.1)
3. SDO-82 Name conflicts with anonymous XSD types (section 2.1.2)
4. SDO-83 Clarification of special "value" property and how to avoid name
clashes (section 2.1.5)

I'd like to further discuss and hopefully vote on these proposals during
next weeks TC call.

Thanks,
Frank


PROPOSAL 1. SDO-67 Handling of Namespace in SDO Path (section 2.1.4)

The resolution to this issue is to extend the SDO Path syntax to support
the namespace-uri() function from standard XPath. Although the syntax is
somewhat ugly, it's important to not invent our own syntax, but instead
conform to the original goal of SDOPath which was to be (mostly) a
compatible subset of proper XPath.

Given the following schema:

    <xsd:complexType name="TwoBars">
        <xsd:sequence>
            <xsd:element name="bar" type="xsd:string"/>
            <xsd:element ref="tns2:bar"/>
        </xsd:sequence>
    </xsd:complexType>

An SDO user can then retrieve the second "bar" property as follows:

dataObject.get("bar[namespace-uri()='http://the-tns2-namespace' <http://the-tns2-namespace'/> ]");

As in previous versions of SDO:

dataObject.get("bar");

would continue to return the first "bar".

The specific change to the SDO 2.1 spec is in section 12, change:

step ::= '@'? property
      | property '[' index_from_1 ']'
      | property '.' index_from_0
      | reference '[' attribute '=' value ']'
      | ".."

to the following:

step ::= '@'? property
      | property '[' index_from_1 ']'
      | property '.' index_from_0
      | property '[' namespace-uri() '=' uri ']'
      | reference '[' attribute '=' value ']'
      | ".."

uri ::= '"' anyURI "'"
      | "'" anyURI "'"


In addition to the above resolution, Stefan has proposed adding the
following methods to XSDHelper:

XSDHelper.getProperty(Type type, String uri, String xsdName, boolean
isElement)
XSDHelper.getInstanceProperty(DataObject, String uri, String xsdName,
boolean isElement)

These methods provide a non-SDOPath alternative for handling this issue as
well as SDO-71. I'm also OK with adding these methods.


PROPOSAL 2. SDO-71 SDOPath handling of '@' character (section 2.1.1)

TestCase in ZIP file: DuplicateNamesTest.testAttributeElementClash()

The resolution to this issue is to require implementations to
automatically mangle the name of attributes that conflict with an element
in a type, and to also specify that XSD attributes will map to properties
that have @name as an aliasName.

Given the following schema:

    <xsd:complexType name="TwoFoos">
        <xsd:sequence>
            <xsd:element name="foo" type="xsd:string"/>
        </xsd:sequence>
        <xsd:attribute name="foo" type="xsd:int"/>
    </xsd:complexType>

This will produce an SDO Type named "TwoFoos" with two properties:

1. name="foo", type=String
2. name="some_mangled_name", type=Int, aliasName="@foo"

An SDO user can then retrieve the foo element as follows:

dataObject.get("foo");

And the foo attribute like this:

dataObject.get("@foo");

Although this solution is not 100% backwards compatible (i.e., it does not
allow an XML element to be accessed using the "@name" syntax), it is
backwards compatible for all practical purposes, since it's highly
unlikely that there are any existing SDO users that rely on the ability to
use the @ syntax to retrieve element properties.

Note 1: with this proposal, an attribute-backed property that appears
after an element-backed property in the getProperties() list does not
necessarily conflict, since the spec already says that in the case of
duplicates the first property will hide the others. Since the goal of this
resolution is to ensure that the element-backed property will always take
precedence we could allow an implementation to choose not to actually
mangle the attribute-backed property name in this case, as long as it
still sets the aliasName as specified above.

Note 2: with this solution SDO Path works with SDO names. The
attribute/element aspects only impact the mapping from XSD to SDO.

The specific changes to the SDO 2.1 spec for this issue are:

1) In section 9.3 change:

If elements and attributes within a complexType, and its base types, have
the same local name then unique names must be assigned by sdo:name.

to the following:

If elements and attributes within a complexType, and its base types, have
the same local name and unique names are not assigned by sdo:name, then an
implementation will automatically rename the attribute property (i.e., the
one for which XSDHelper.isAttribute returns true) to an
implementation-dependent mangled name.

(NOTE, do we want to open another issue to consider standardizing the
mangled name used for conflicting attributes? Personally, I think that if
users care, they should use sdo:name annotations.)

2) In section 9.3.1, first row of the table (i.e., "Attribute" row),
change:

Property name=[NAME]
  type=[TYPE]

to the following:

Property name=[NAME]
  type=[TYPE]
  aliasName=@[NAME]

3) In section 12, change:

step ::= '@'? property
      | property '[' index_from_1 ']'
      | property '.' index_from_0
      | reference '[' attribute '=' value ']'
      | ".."
property ::= NCName      ;; may be simple or complex type
attribute ::= NCName     ;; must be simple type
reference :: NCName      ;; must be DataObject type

to the following:

step ::= property
      | property '[' index_from_1 ']'
      | property '.' index_from_0
      | reference '[' attribute '=' value ']'
      | ".."
property ::= sdoName      ;; may be simple or complex type
attribute ::= sdoName     ;; must be simple type
reference ::= sdoName      ;; must be DataObject type
sdoName ::= '@'? NCName

Also in section 12, change:

The presence or absence of the @ sign in a path has no meaning. Properties
are always matched by name independent of their XML representation.

to the following:

Unlike standard XPath, the @ sign is not required for accessing
attribute-backed properties. It can be used to access properties that have
an aliasName that includes the @ sign, typically XML attributes - see
section 9.3.1.


PROPOSAL 3. SDO-82 Name conflicts with anonymous XSD types (section 2.1.2)

TestCase in ZIP file: DuplicateNamesTest.testAnonymousTypeClash()

This issues has already been partially resolved in SDO 2.1.1 (JSR 235). In
JSR 235 it was agreed that anonymous types in locally defined elements are
automatically mangled so as not to conflict with global types. For
example:

    <xsd:complexType name="personRoot">
        <xsd:sequence>
            <xsd:element name="person">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="identifier" type="xsd:string"/>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>

Unlike SDO 2.1, in SDO 2.1.1 the anonymous type declared under the local
"person" element will not conflict with a global type "person" such as:

    <xsd:complexType name="person">
        <xsd:sequence>
          <xsd:element name="firstName" type="xsd:string"/>
          <xsd:element name="lastName" type="xsd:string"/>
        </xsd:sequence>
    </xsd:complexType>

However, in JSR 235 it was not required that an implementation also mangle
the name of an anonymous type under a global element:

    <xsd:element name="person">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="name" type="xsd:string"/>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>

The proposed resolution to this issue is to take the extra step to say
that the name of this anonymous type must also be mangled. This is
required in order for SDO to guarantee that:

typeHelper.getType(NS_DUPLICATES, "person");

will always return a real globally defined complexType, as above.

The specific change to the SDO spec for this issue is:

1) the changes to reflect the resolution of the issue in JSR 235
2) State clearly that anonymous types (under local or global
elements/attributes) will never be given name that hides a globally
defined type with the same name.


PROPOSAL 4. SDO-83 Clarification of special "value" property and how to
avoid name clashes (section 2.1.5)

TestCase in ZIP file: DuplicateNamesTest.testValuePropertyClash()

Since only attributes named "value" can conflict with the special "value"
property, the solution to Proposal 2 (SDO-71) will also solve this issue,
as long as the special "value" property is treated like an element-type
property. This will be the case, given the proposed wording for SDO-71,
that is, it uses XSDHelper.isAttribute() as its test. Therefore, since the
special "value" property is not an attribute, it will be treated like an
element.



---------------------------------------------------------------------
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]