[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: AW: AW: [sdo] Update of remaining XML Fidelity duplicate namesissues
Hi Radu,
I think it would look something like this:
sdoName ::= '@'? NCName ( '[' namespace-uri() '=' uri ']' )?
uri ::= '"' anyURI '"'
| "'" anyURI "'"
I'm not a language grammar expert, but I think that if you make
"namespace-uri()" a token, it's still LR(1), or something like that.
Frank.
"Radu Preotiuc-Pietro" <radu.preotiuc-pietro@oracle.com>
08/11/2008 09:53 PM
Please respond to
"radu.preotiuc-pietro@oracle.com" <radu.preotiuc-pietro@oracle.com>
To
"sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
cc
Subject
RE: AW: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names
issues
Frank,
Are you envisioning sdo names including the ":" and "[" characters?
In Proposal 2 you have introduced an sdoName non-terminal:
sdoName ::= '@'? NCName
What would this become? Wouldn't that make our SDO Path grammar
context-sensitive?
Radu
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: Monday, August 11, 2008 3:49 PM
> To: sdo@lists.oasis-open.org
> Subject: Re: AW: AW: AW: [sdo] Update of remaining XML
> Fidelity duplicate names issues
>
> Hi Ron, Blaise,
>
> I agree with Ron that it's important that get("bar") continue
> to return the first bar.
>
> I think the following suggestion of Blaise's might be a breakthrough:
>
> > 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']".
>
> At first glance it seems quite strange to think of a property
> name like
> this: "bar[namespace-uri()='http://the-tns2-namespace']". But
> it's strange for a good reason: XPath compatibility. Here's a
> slight refinement that I think may work really well:
>
> The two properties names are:
>
> 1) bar
> 2) bar (or maybe an implementation dependent mangled name)
>
> The two properties have the following aliasNames:
>
> 1a) bar[namespace-uri()='http://the-target-namespace'] if the
> element form is qualified
> 1b) bar[namespace-uri()=''] if the element form is unqualified
> 2) bar[namespace-uri()='http://the-tns2-namespace']
>
> This way, we can access the first bar using get("bar") and
> either property using the standard XPath namespace-uri() syntax.
>
> Thoughts?
>
> Frank
>
>
>
>
> "Barack, Ron" <ron.barack@sap.com>
> 08/11/2008 05:47 PM
>
> To
> "Blaise Doughan" <blaise.doughan@oracle.com>,
> <sdo@lists.oasis-open.org> cc
>
> 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:
> 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_XM
> L_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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]