[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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']"); 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]