[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [sdo] Update of remaining XML Fidelity duplicate names issues
Hi guys,
I've spent quite a bit of time thinking about and discussing the attached
proposal within IBM, but unfortunately the conclusion is that we don't
find it to be an acceptable solution for these issues. By this, I mean the
SDOPath part of the proposal (option 1 or 2). As we agreed (and voted) in
last week's TC call, we do like and support the XSDHelper.getProperty()
part of the proposal.
The problem with the SDOPath part of the proposal is that it doesn't meet
our (IBMs) goal of XPath Fidelity. IBM feels that XPath Fidelity is an
important part of XML Fidelity in general. That is, SDOPaths should be as
compatible with XPath as possible and thus as natural as possible for an
XML-savvy programmer to use. Neither using xml: prefixes in the path nor
using (verbose) function syntax meets this requirement. We also don't see
a use case that would require the ability to mix SDO name matching and XML
name matching within the steps of a single path, so the additional
complexity is not warranted in our view.
Given that it appears that others don't feel as strongly about XPath
Fidelity, and since we need to start making more progress given our target
date for SDO 3, we feel it would be best to end the discussion of these
issues and simply leave the spec as it is, only making sure that
implementations are allowed to solve these issues in
implementation-dependent ways. Although we realize that this is less
satisfying than to agree on a standard solution, we feel that the
XSDHelper.getProperty() method that we've agreed to already provides one
way to handle duplicate names. We believe that also handling them though
SDOPath via an implementation-dependent approach will be good enough.
I believe that the IBM solutions to these issues (described below) are
arguably compliant with the spec already. This conclusion is based on one
of my favorite paragraphs in the spec :-) That is, section 3.1.3:
SDO specifies minimum functionality for implementations. An implementation
may provide additional function so that valid results would be returned
where this specification would produce an error, provided that the
functionality is a strict superset and all valid uses of the SDO
specification operate correctly.
Also, this wording in section 12:
names including any of the special characters of the syntax (./[]='"@) are
not accessible.
I interpret section 12 to mean get("@foo") would be an error condition.
However, according to 3.1.13 an implementation can "provide additional
function" in this case. IBM, for SDO-71 (for example), would go the route
of providing the additional function of adding "@foo" as an aliasName for
attribute backed properties named "foo" and then allowing them to be
accessed through DataObject.get("@foo").
Does anybody believe that we are wrong in this assumption, in that this
would make IBM's implementation of SDO noncompliant? The only possible
issue I can see is this sentence in section 12:
The presence or absence of the @ sign in a path has no meaning.
This seems to imply that implementations MUST implement get("@foo") to
return an element-backed property, if it is the first foo in the list. In
my opinion, a user would likely consider this an error. It conflicts with
the purpose of allowing the @ sign in the first place (to allow standard
XPath syntax to be used to retrieve attribute-backed property values).
Although, maybe IBM could argue that our implementation provides
"additional function" in this case as well - i.e., in our implementation
the presence or absence of the @ sign in a path HAS meaning.
Does anybody believe that the SDO spec should say that an implementation
is noncompliant if it doesn't return an element from get("@foo"), when the
first foo property is an element? I think that, as we've always tried to
do in the past, it would be in SDO's best interest to remove this (or any
other) wording that appears in the spec which is necessary in order to
allow this to be compliant (i.e., allow an implementation to do better).
Thanks,
Frank
Blaise Doughan <blaise.doughan@oracle.com>
08/26/2008 09:44 AM
To
sdo@lists.oasis-open.org
cc
Subject
Re: AW: [sdo] Update of remaining XML Fidelity duplicate names issues
Hello All,
Attached is the Oracle proposal addressing the following SDO issues:
SDO-67 Handling of Namespace in SDO Path (section 2.1.4)
SDO-71 SDOPath handling of '@' character (section 2.1.1)
SDO-83 Clarification of special "value" property and how to avoid name
clashes (section 2.1.5)
-Blaise
Frank Budinsky wrote:
Hi guys,
The current status of at least SDO-67 is that we're waiting to evaluate a
counter proposal from Oracle. I'm not sure if it will also address SDO-71
(or SDO-83, which the current SDO-71 proposal also solves). If so, we need
to see this proposal and evaluate it ASAP. Otherwise, I'd like to suggest
making SDO-71 an optional feature. All that's needed for that is to
"allow" SDO names to include the '@' character after which IBM, or anyone
else that wants to, could implement SDO-71 as described below, and still
be spec compliant.
The final issue below, SDO-82, is unrelated. Are there any objections to
that proposal? If not, can we at least resolve it?
It looks like our tentative plan to publish a CD by the end of August is
becoming highly unlikely. I think we need to put a greater sense of
urgency on making progress on this spec, or I feel that SDO 3 may come
unravelled.
Comments?
Thanks,
Frank
"Barack, Ron" <ron.barack@sap.com>
08/11/2008 06:32 AM
To
Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
cc
Subject
AW: [sdo] Update of remaining XML Fidelity duplicate names issues
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']");
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
SDO3-XMLFidelityAndSdoPath.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]