AW: [sdo] XML Fidelity duplicate names issues

["Buennig, Stefan" <stefan.buennig@sap.com>]

Hi Frank,

your proposals are a good step forward for SDOs XML fidelity.
Here are my comments:

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

The proposal is ok, but the syntax doesn't look very easy.
I expected something that uses the hash sign # we know from Qnames. But may be that would be too difficult to parse in case of chained paths.

In addition we should define the meaning of URI for properties.
My proposal: If a property has to be rendered in XML with a prefix to be valid against it's schema then the URI is the URI that is represented by the prefix otherwise the URI is an empty String "".

I think this would reduce confusions about the meaning of the properties URI in case of elementFormDefault and attributeFormDefault is unqualified.
The same should be valid for XSDHelper.getNamespaceURI(Property)

With this definition we have a well defined access to the properties of the following root-object:

<ns:root xmlns:ns="http://test.org"; ns:prop="attribute1" prop="attribute2">
  <ns:prop>element1</ns:prop>
  <prop>element</prop>
</ns:root>

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

I think, we should avoid any automatic name-mangling for properties. With different namespaces we already have conflicting property names and so the element/attribute conflict doesn't make the things worse.
I also would not append an alias with the '@'-sign. I'd rather see the '@' as part of the path-syntax than as part of the property name or alias.

Here is an example where name mangling would fail:

First you parse this schema S1.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test.org";>
	<xs:complexType name="T1">
		<xs:attribute name="prop" type="xs:string"/>
	</xs:complexType>
</xs:schema>

If I understood you right the attribute name will not be mangled because there is no conflict.

Later you parse this schema S2.xsd with the same XSDHelper:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test.org"; xmlns:tns="http://test.org";>
	<xs:include schemaLocation="S1.xsd"/>
	<xs:complexType name="T2">
		<xs:complexContent>
			<xs:extension base="tns:T1">
				<xs:sequence>
					<xs:element name="prop" type="xs:string"/>
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
</xs:schema>

When you parse the second schema it is too late to rename the attribute.

We have a customer who is very paranoid about such cases.

Regards,
Stefan.

-----Ursprüngliche Nachricht-----
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Gesendet: Mittwoch, 23. Juli 2008 22:11
An: sdo@lists.oasis-open.org
Betreff: [sdo] XML Fidelity duplicate names issues

As mentioned in the last OASIS call, I would like to submit proposals for 
solutions to several XML Fidelity issues, specially the issues described 
in section 2.1 of: 
http://www.oasis-open.org/committees/download.php/26722/SDO_XML_Issues.doc

I would also like to propose that we publish an interim SDO 3 committee 
draft, which includes these and the other resolved issues so far, by the 
end of August. How do others feel about this date?

The OASIS JIRAs corresponding to the issues in section 2.1 of the above 
document are:

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)
5. SDO-? (NEW) Type of merged property for duplicate elements (section 
2.1.3)
6. SDO-? (NEW) isMany value of merged property for duplicate elements 
(section 2.1.3)

The following describes the proposed resolution to each of these issues. 
I've also attached a test program that illustrates the expected behavior 
for each issue.



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

TestCase in ZIP file: DuplicateNamesTest.testPropertyURIClash()

The resolution to this issue is to extend the SDO Path syntax to support 
the namespace-uri() function from standard 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']");

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 "'"


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.

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.


PROPOSAL 5. SDO-? (NEW) Type of merged property for duplicate elements 
(section 2.1.3)

TestCase in ZIP file: DuplicateNamesTest.testSequenceWithDuplicates()

The resolution to this issue is as described in section 2.1.3. More 
specifically, in section 9.3.2 of the SDO 2.1 spec change:

The type of the property is SDO Object.

to the following:

The property's type is that of the elements, which if the schema is valid 
must all be the same.


PROPOSAL 6. SDO-? (NEW) isMany value of merged property for duplicate 
elements (section 2.1.3)

TestCase in ZIP file: DuplicateNamesTest.testChoiceWithDuplicates()

The resolution to this issue is as described in section 2.1.3. More 
specifically, in section 9.3.2 of the SDO 2.1 spec change:

A single property is used for all the elements with the same local name 
and the same targetNamespace, where isMany=true. 

to the following:

A single property is used for all the elements with the same local name 
and the same targetNamespace. If the content model allows more than 1 
instance of the element, then isMany=true. If, however, the elements are 
mutually exclusive (for example, they are single valued and on two sides 
of a xsd:choice group), then isMany=false.