[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicatenames issues]
-------- Original Message --------
Hi Blaise, > We would then need to have 2 definitions for a step: Not really, because the definition of the XML name is where it appears: xmlName ::= xmlAttribute | xmlElement xmlAttribute ::= '@' NCName xmlElement ::= NCName It's really because of this distinction between element and attribute names, that using XML names is a solution to the duplicate problem in the first place. > At the end of the day with your proposal '@' becomes an invalid character rather than an ignored one, and most implementations will need to continue to ignore the '@' character for backwards compatibility reasons. Yes, but it's use is not recommended/endorsed going forward. > Because of section 3.1.13 we will never be able to compliance test invalid SDO paths. That's nothing new and not a problem in my opinion. Frank. Blaise Doughan <blaise.doughan@oracle.com> 09/08/2008 02:19 PM To sdo@lists.oasis-open.org cc Subject Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues Hi Frank, Removing the following line from section 12 would make '@' an invalid character in SDO path: step ::= @'? property We would then need to have 2 definitions for a step: SDO path based on SDO names - step ::= property SDO path based on XML names - step ::= @'? property You are correct the following line would not be necessary. This is because @ would be significant when based on XML names and not allowed when based on SDO names: "The presence or absence of the @ sign in a path has no meaning." At the end of the day with your proposal '@' becomes an invalid character rather than an ignored one, and most implementations will need to continue to ignore the '@' character for backwards compatibility reasons. Because of section 3.1.13 we will never be able to compliance test invalid SDO paths. -Blaise Frank Budinsky wrote: Hi Blaise, I don't know what I said that led you to this conclusion: Your proposal then is to allow '@' to be a valid an meaningful part of an SDO name restricted to the first character. That's not what I'm proposing. This is exactly what I'm proposing: Part 1) Use the xml: prefix at the beginning of the path to indicate XML matching is being used (this is the restricted version of your proposal). This is the proper (standard) solution to SDO-67, SDO-71, and SDO-83. Part 2) Take @ out of the SDO path syntax. Specifically, make the following changes to the spec: 2a) change this line in section 12: step ::= @'? property to the following: step ::= property 2b) and remove this sentence from section 12: "The presence or absence of the @ sign in a path has no meaning." The justification for this change is because the spec currently says that @ can be used in a SDO name-based path, but has no meaning. It would be better to say nothing about @ then to say it's supported in the syntax, but doesn't work as one would expect. Also, since @ is properly supported in the XML name-based syntax - i.e., get("xml:@foo") - it's really no longer needed in the SDO name-base path syntax. If an implementation wants to provide backwards compatibility for @ or some kind of special handling of @ (whether it's good, bad, or even possible to do anything useful), it can do that given the paragraph in section 3.1.13 that says an implementation can "provide additional function ...". I think the spec, however, should neither require nor prevent any handling of @, other than in the "xml:@foo" case. Thanks, Frank. Blaise Doughan <blaise.doughan@oracle.com> 09/08/2008 10:42 AM To sdo@lists.oasis-open.org cc Subject Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues Hi Frank, Your proposal then is to allow '@' to be a valid an meaningful part of an SDO name restricted to the first character. This would mean that a property corresponding to an XML element could be called "@foo" and used as part of an SDO path such as "@foo/bar", this example would break XPath fidelity. With this change: get("foo") - could return info corresponding to an XML attribute get("@foo") - could return info corresponding to an XML element I agree with the following statement from the end of section 12, "Properties are always matched by name independent of their XML representation.". If the presence of '@' is confusing users of SDO path then my preference would be to move in the direction of disallowing it rather than allowing it. Guarantee that an attribute won't hide an element (Is this still a requirement?) I do not see how this requirement could be supported. Consider the following XML schema: <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:example" targetNamespace="urn:example" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:complexType name="parent"> <xs:attribute name="foo" type="xs:string"/> </xs:complexType> <xs:complexType name="child"> <xs:complexContent> <xs:extension base="parent"> <xs:sequence> <xs:element name="foo" type="xs:string"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema> For the types derived from the above XML schema, I would expect the following code to be valid: Type parentType = typeHelper.getType("urn:example", "parent"); Property parentTypeFooProperty = parentType.getProperty("foo"); xsdHelper.isAttribute(parentTypeFooProperty); // returns true Type childType = typeHelper.getType("urn:example", "child"); Property childTypeFooProperty = childType.getProperty("foo"); xsdHelper.isAttribute(childTypeFooProperty); // returns true I would not expect the name of the foo property on the parent type to be mangled because there is no conflict on that type (also if the types were created from DataObjects the parent type could have been created long before the child type). I would also expect the get("foo") call on an instance of the child type would refer to the same property as the get("foo") call on an instance of the parent type. -Blaise Frank Budinsky wrote: Hi Blaise, Sorry if I wasn't clear about what I'm proposing for #2. All I want to do with the spec is to take out any mention of the @ character in normal SDO name based paths. That is remove '@'? for the syntax: step ::= '@'? property And remove the sentence that says this: The presence or absence of the @ sign in a path has no meaning. Then the only "standard" spec use where @ would be allowed is: o.get("xml:@foo") --- where "@foo" is simply an XML name of a property. Anything else that IBM or some other implementation wants to do to also support: o.get("@foo") - would be additional (nonstandard) function not defined by the spec. I don't want to leave the spec exactly the way it is, because it is currently saying that @ is supported in front of SDO names, but it has no meaning. What problem is that solving, especially given that it may return an element. Does this make sense? Frank. Blaise Doughan <blaise.doughan@oracle.com> 09/05/2008 01:53 PM To sdo@lists.oasis-open.org cc Subject Re: AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues Hello Frank, Wrt the compromise proposal: 1. I am OK with the indicator applying to the SDO path as a whole, users will use either all SDO names or all XML names. 2. You are asking that '@' be a significant character in SDO names and alias names (i.e. "@foo", "f@oo", and "foo@" would be valid), so that implementation can choose to name mangle or auto-alias SDO names using that character. Allowing the character in the middle of the name appears to break your own XPath fidelity requirement ("f@oo" is not a valid XPath). The alternative is to restrict "@" to be the first character of SDO names of properties that correspond to XML attributes, this would NOT be acceptable to Oracle as it is an unnecessary complication to a problem our proposal already addresses. -Blaise Frank Budinsky wrote: Hi Ron, If I'm understanding it right, I think there are a couple of problems with your approach. 1) You say that this approach gives the implementation the CHOICE not to do name mangling, but in reality it REQUIRES the implementation not to do name mangling if it wants o.get "x[namespace-uri()='foo']") to work. The problem is that if there are duplicates and static code is to be generated, the only "standard" way to do it is to rename the property (unless we also add the sdoj:javaName annotation like SAP - but I really don't want to add that extra complexity to the spec either). 2) Building on your description of how "x[namespace-uri()='foo']" works, I assume that "@x" would work similarly: i.e., it matches the property where p.getName().equals("x") and also XSDHelper.isAttribute(p) == true. This would ensure that o.get("@x") returns the attribute, but it wouldn't guarantee that o.get("x") will return the element (in the duplicate case). We haven't provided a guarantee that an attribute won't hide an element. I really don't think it's possible to handle these cases without some kind of mangling/aliasName approach, unless we just go with the Oracle solution of using xml: to specify that the XML name matching should be used. That is: o.get("xml:x"); o.get("xml:@x"); o.get("xml:x[namespace-uri()='foo']"); The main objection to this is that the xml: prefix is possible at any step. We (IBM) see no use case that justifies this added flexibility at the expense of making the entire path something that is not XPath compatible. Here's another compromise proposal: 1) we say that xml: can only appear at the beginning of the path (similar to what's already defined in the spec, although as we've discussed previously, maybe we need to change the ":" to "::", or maybe a different character like "#" or "$"). It means XML name matching is used for all steps in the following path, which would be XPath compatible. This would be the the"standard" solution. 2) make any minor changes to the wording of the non "xml::" case which are necessary to allow implementations to also provide another implementation-dependent solution (as I proposed below). Would this be acceptable to others? Thanks, Frank "Barack, Ron" <ron.barack@sap.com> 09/05/2008 08:02 AM To Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org> cc Subject AW: AW: [sdo] Update of remaining XML Fidelity duplicate names issues Hi Frank, others, I think we should try a little harder, here. SAP is part of the camp that does not think of SDOPath's similarity to Xpath as being required for XML fidelity, but we do see the need to to have a SDOPath with a readable, understandable syntax, that can address any property. I think SDO will be weakened if we don't offer some standard solution here. We at SAP can live with Oracle's as well as IBM's proposals, maybe we will have luck and be able to find a middle ground. One reason why I think the "xml:" notation is superior to IBM's proposal is that it allows implementations more flexibility in deciding how to handle conflicting local names, that is, it allows implementations to mangle the SDOName. Or not. The XML name, qualified by "@" or by "namespace-uri" seems to be our only chance of coming up with a standard way to name the property for the purposes of SDOPath. But while allowing for name mangling, Oracle's proposal (I mean here proposal 1) does not require it. As I understand the current proposal, however, the "xml:" prefix is not really othogonal to the "namespace-uri" predicates, namely, the "namespace-uri" can only in association with "xml:". One thing we could do is weaken this, allow namespace-uri to be used with or without the "xml" prefix. First of all, we need to weaken it anyway, to handle open content properties, So why not just say the two predicates are orthogonal. One way to look at an SDOPath element is that it's a query on the metadata. Saying o.get("x") essentially performs a query on the instance properties, returning the property where p.getName().equals("x"). Saying o.get("x[namespace-uri()='foo']") is simply adding another clause to the query, asking that additionally XSDHelper.getNamespaceURI(p).equals("foo"). If we go in this way, then at least we give the implementation the choice not to do any name mangling, and for such implementations, since the SDO name will be the same as the XML name, the "xml:" prefix becomes optional, so the SDOPath string becomes exactly what Frank suggested in his proposal. True, this will be implementation specific behavior, as will any behavior that relies on the implementation's name mangling algorithm. But at least we have a standard, portable solutions that allows the vendor specific solution that IBM would prefer. We could also go to the other extreme and say that namespace-uri implies the use of an XML name, that is, that "xml:" is redundant in this case. Then we also get SDOPaths that look like Xpath, but we loose the ability to use the SDO name with namespace-uri. I also think it's a bit convoluted for one clause in the "metadata query" to affect the meaning of the other clause. Regarding the "@" operator... It's true that using it to distinguish attributes and elements is a breaking change. It would, however, be a breaking change that is in SAP's opinion fully acceptable: we don't think may users are relying on this behavior, we don't think there will be many breaks. Blaise's arguement that the character sets us up for further extensions of other datacentric languages is something I haven't really been able to understand. Perhaps, Blaise, you could describe what such a possible future extension might be. Otherwise, I would rather try to get a consensus solution to the current issues. Ron -----Ursprüngliche Nachricht----- Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Freitag, 5. September 2008 03:29 An: sdo@lists.oasis-open.org Betreff: 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 --------------------------------------------------------------------- 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]