OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes


Could we add a new signature for getInstanceProperties such as getInstanceProperties(bool getTechnical) instead?

Thanks,
  James


-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Sent: Monday, June 23, 2008 4:04 PM
To: sdo@lists.oasis-open.org
Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes

Hi James,

To me, "meta" implies a change in the description level - that is, 
meta-data describes data, meta-meta-data, describes meta-data, and so on. 
So the name 
"meta property" would imply that it is describing a property, as opposed 
to being a special "hidden" property.

Technical property, on the other hand, is not a terrible name, but IMO not 
really very obvious what it is. I'm not sure if "system" is really much 
better, but I think it may be a little better.

I'd rather not add a new method to DataObject (it has more than enough 
already), if we can avoid it.

Thanks,
Frank.


"James Hart" <James.Hart@roguewave.com> wrote on 06/23/2008 05:15:29 PM:

> I am not sure why "meta properties" didn't catch on.  I don't really
> care what it is called and I don't think this should ever be 
> confused with anything XMLcentric, it is and SDO thing that 
> XML/XSDDas/Helper would simply be utilizing. 
> 
> getTechnical(Meta|System)Properties would be on the same objects as 
> getInstanceProperties is, so DataObject and Type, is 
> getInstanceProperties on anything else?  The proposal is that these 
> Meta Properties are simply instance properties where 
> is(Meta|Technical|Whatever) property of the instance property is 
> true and these type of instance properties can be added at anytime 
> even on closed types and data objects.  They should be ignored in 
> the normal flow of things that is why they wouldn't be part of the 
> getInstanceProperties list.
> 
> I wouldn't want to tie these to anything xmlcentric such as the xml 
> attribute solution.  Simply making them special kinds of instance 
> properties makes it very robust and general for any mechanism to 
> take advantage of.  If it is decided to make xmlcentric than going 
> back to a isNill/setNill api would be as desirable to me (as in not 
> very desirable).
> 
> 
> Thanks,
>   James
> 
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Sent: Monday, June 23, 2008 2:54 PM
> To: sdo@lists.oasis-open.org
> Subject: RE: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi Guys,
> 
> I think something like "system properties" might be a better name than 
> "technical properties". XML has 4 intrinsic system/technical properties, 

> namely the 4 attributes in the xsi namespace: xsi:type, xsi:nil, 
> xsi:schemaLocation, and xsi:noNamespaceSchemaLocation. These 4 are 
> built-in attributes that all XML processors allow. I think we need to 
say 
> that those 4 are system properties by default. If users want to define 
> additional ones, they can do it with Ron's proposed sdo annotation (but 
> note that they can result in invalid XML serializations).
> 
> I'm not really crazy about adding a new API for this to SDO. Where would 

> getTechnicalProperties() go? DataObject, DataHelper, or somewhere else? 
I 
> wonder if we could require technical/system properties to map to XML 
> attributes? If so, maybe we could access them using a solution we might 
> come up with for SDO-132?
> 
> Frank
> 
> 
> 
> 
> "James Hart" <James.Hart@roguewave.com> 
> 06/19/2008 09:23 AM
> 
> To
> "Barack, Ron" <ron.barack@sap.com>, Frank Budinsky/Toronto/IBM@IBMCA, 
> <sdo@lists.oasis-open.org>
> cc
> 
> Subject
> RE: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> 
> 
> 
> 
> 
> I really like this more generalized approach with "Option 2".
> 
> It would also be nice if there was an additional API similar to 
> getInstanceProperties() that would be PropertyList 
> getTechnicalProperties().  In the long run it would even be nicer if 
there 
> becomes a getTechnicalProperties(Namespace) api.  That way a user of the 

> technical properties wouldn't have to getProperty(TProp) on everything 
it 
> may know about, but instead get a list, loop through them and see if it 
> recognizes any of them.
> 
>   One benefit comes if there is a larger overhead in multiple calls to 
> getProperty() than a single getTechnicalProperties() call. Another 
benefit 
> is if a DAS may recognize 100 technical properties but likely there will 

> only be one or two ever set on any type or data object it will save a 
> large amount of time to get a list and check if it recognizes those.
> 
> Thanks,
>   James
> 
> -----Original Message-----
> From: Barack, Ron [mailto:ron.barack@sap.com] 
> Sent: Thursday, June 19, 2008 4:25 AM
> To: Frank Budinsky; sdo@lists.oasis-open.org
> Subject: AW: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi,
> 
> I would like to propose generalizing Option 2 below as follows.  We 
define 
> an open content property
> {commonj.sdo}technicalProperty with type "boolean".
> 
> When an open content property is annotated with 
technicalProperty="true", 
> then the property may be set on any object, regardless of whether the 
> object's type is open or not.  This is the behavior described under 
> "Option 2", except now it is not based on a pre-defined set of 
properties 
> hardcoded into SDO, but rather on the "technicalProperty" mechanism.
> 
> Technical properties DO NOT appear in an object's instance properties. 
> Instance properties are typically business relevant, technical 
properties 
> are not.  Technical properties can only be retrieved or set through the 
> DataObject.get(Property) or the DataObject.set(Property, Object) APIs.
> 
> We must further define the open content property 
> {http://www.w3.org/2001/XMLSchema-instance}nil"; and declare it to have 
> technicalProperty="true".
> 
> Best Regards,
> Ron
> 
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Gesendet: Montag, 16. Juni 2008 21:02
> An: sdo@lists.oasis-open.org
> Betreff: RE: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi James,
> 
> If I understand you, you're suggesting 1) a generic mechanism for adding 

> meta information to meta information, and 2) a separate API for 
accessing 
> instances of this meta information.
> 
> For 1), I think the instanceProperty support we added to Type and 
Property 
> 
> is mostly what we need (except, I suppose, it's missing a set() API if 
the 
> 
> types are defined with XSD).
> 
> For 2), I'm not sure I see the value of adding the complexity of a 
> separate API for this. Simply using DataObject.get/set() seems like a 
very 
> 
> clean and simple approach to me.
> 
> Frank.
> 
> 
> 
> 
> "James Hart" <James.Hart@roguewave.com> 
> 06/11/2008 10:15 AM
> 
> To
> "Barack, Ron" <ron.barack@sap.com>, <sdo@lists.oasis-open.org>
> cc
> 
> Subject
> RE: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> 
> 
> 
> 
> 
> I like option two, but can we make it more generic?  Could we just have 
a 
> method on Type and Property such as 
> set/getMetaProperty<val_type>(property, xmlnamespace, name, value). This 

> would be an instance property but only accessable through this API and 
> only should be used for auxiliary information that is critical to the 
data 
> 
> itself.
> 
> In this way we could say something like any meta property can be added 
to 
> any kind of property.  By best practice it would only store meta 
> information that would only be important to a DAS or a user that expects 

> auxiliary information from a DAS. We could even expand that and say that 

> certain projects would use these meta data to hold their own custom 
states 
> 
> and this is also how the projections can "share" information with other 
> projections. 
> 
> So in terms of the nil property now when the XSDHelper reads in an xsd 
it 
> could do:
>  Type<bool>.addMetaProperty(nillableElementProperty, xsdnamespace, 
> "nillable", true); 
> 
> And when the XSDHelper reads in a file where something is set, when it 
is 
> creating the DataObject it could do something like:
> DataObject.<bool>setMetaProperty("thiselementwasnill", xsdnamespace, 
> "nill", true);
> 
> So now if the user wants to tell the XMLDas to marshall out something as 

> nill they would:
> DataObject.<bool>setMetaProperty("thiselementwasnill", xsdnamespace, 
> "nill", true);
> 
> And then the XMLHelper on read just simply would check to see if the 
> "nillable" meta information is on the type and if it is check to see if 
> the xsd:nill meta information is set to true on the actual property 
where 
> the elements dataObjectType is located.
> 
> Now the user can use introspection on the meta properties to get meta 
> information that was XML or any other medium specific meta information. 
> But I think the really cool thing about this is that any kind of DAS can 

> add any kind of information and now interop with compatible meta 
> information from other DAS's. 
> 
> So I guess the solution I am proposing is a more robust system that 
allows 
> 
> for meta information that isn't XML centric but generic enough to hold 
any 
> 
> kind of meta information.  One might argue since you can put instance 
> properties on types that this already a way to provide meta information. 

> However, there is no real way currently to provide instanced meta 
> information on properties on a DataObject that has no relation to the 
> stored information.
> 
> Of course this is all just very preliminary in of an idea and maybe 
there 
> are still use cases it doesn't cover well, but if this system was in 
place 
> 
> for 2.1 I think I could of implemented an XSDHelper in such a way it 
would 
> 
> of provided all the meta information needed so XMLHelper could of 
> inspected a type created by the XSDHelper and generated a valid XML 
> instance document, which is valuable because we have ran into a couple 
of 
> customer use cases for that.
> 
> Thanks,
>   James
> 
> 
> 
> -----Original Message-----
> From: Barack, Ron [mailto:ron.barack@sap.com] 
> Sent: Wednesday, June 11, 2008 6:47 AM
> To: sdo@lists.oasis-open.org
> Subject: AW: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi SDO-ers,
> 
> I want to bring up some additional options for dealing with xsi:nil. 
> 
> OPTION 1:
> 
> This is more or less motivated by how JAXB deals with xsi:nil.  JAXB 
> defines JAXBElement, which more or less corresponds to the elements in 
our 
> 
> own beloved Sequence.  JAXBElement has a property "isNil", by extension, 

> we could add an "isNil(int index)" to Sequence, plus a corresponding 
> setter.
> 
> The implication would be that types that have elements with 
> xsi:nillable="true" would be sequenced.  Since there are costs 
associated 
> with sequenced types, we might make to make this rule more precise.  We 
> could say, that nillable implies sequenced only if the element's type 
does 
> 
> not extend a simple type.
> 
> OPTION 2:
> 
> We define a set of global properties that can be set on objects whether 
or 
> 
> not object.getType().isOpen() is true.  Among these global properties 
> would be "xsi:nil" and maybe others, like "xml:lang".  So, to set an 
> object to nill, you'd have to look up the global property (using 
> TypeHelper or XSDHelper):
> 
>                  Property nilProperty = 
> XSDHelper.INSTANCE.getGlobalProperty(
>                                             "
> http://www.w3.org/2001/XMLSchema-instance","nil",false);
>       dataObject.set(nilProperty,true); 
> 
> It's not easy, but doesn't have to be easy, since I consider this pretty 

> much a corner case.  The next question is whether or not such properties 

> should appear in the instance properties of an object.  My first 
> impression is that they should not, they are not business properties but 

> only relevant to XML serialization.  But maybe someone can convince me 
> that they are business relevant.
> 
> It would be the user's responsibility to set this only where the object 
is 
> 
> used as the value of a nillable property.
> 
> I like the second proposal, I think we are introducing something that 
can 
> also be used to solve other problems.  My reservation is that we are 
> effectively making everything "half-open"... But isn't that the way XML 
> is?
> 
> 
> Ron
> -----Ursprüngliche Nachricht-----
> Von: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Gesendet: Montag, 9. Juni 2008 22:56
> An: sdo@lists.oasis-open.org
> Betreff: Re: WG: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi Guys,
> 
> There are no restrictions on xsd:nillable. Any element declaration can 
> have "nillable=true". It can have simple or complex type. So Ron is 
right 
> that Blaise's option 2 is ruled out.
> 
> My feeling is the getValue()/setValue() approach that Ron is suggesting 
is 
> 
> 
> a very XML-specific concept, since it's still only used for XML 
purposes: 
> 1) complexTypes with simpleContent and 2) for xsi:nil. If that's true, 
> then it really doesn't seem right to add it to the DataObject interface.
> 
> Yes, the project(Node.class) I'm suggesting would be providing a "live" 
> Node-view of the DataObject. I don't really think it's that hard. It's 
> very similar to the Sequence-view - just a slightly different "standard" 

> API. I'd like to discuss it in this weeks call, if we can spend a little 

> bit of time on it.
> 
> Thanks,
> Frank.
> 
> 
> 
> 
> "Barack, Ron" <ron.barack@sap.com> 
> 06/09/2008 08:48 AM
> 
> To
> <sdo@lists.oasis-open.org>
> cc
> 
> Subject
> WG: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> 
> 
> 
> 
> 
> Hi Blaise, Everyone
> 
> Looking at the example in section 2.7, we see IntegerRange is simply a 
> complex type, not a complex type that extends a simple type.  Therefore, 

> AFAICS, it has no value property. 
> 
> We couldn't find any limitations on which elements can be marked 
> "nillable".  But we are not the XSD experts, perhaps someone in the 
group 
> can identify what (if any) restrictions exist.  In any case, I assume 
> Frank's example to be valid.  In this case, option 2 falls out, and we 
> have no way to express both that the "min" is set and that the value of 
> the property is nil.  I think we need some API changes.
> 
> My gut feeling, however, is that Blaise is on the right track, in 
> considering nillable and simple content together.  The current way of 
> handling complex types that extend simple context, through the 
> introduction of an artificial "value" property, is problematic because 
it 
> leads to name conflicts.  We already have this on our list of issues to 
be 
> 
> 
> addressed in 3.0.  Perhaps we can address these issues together.  One 
idea 
> 
> 
> would be to create a DataObject.getValue() and a 
> DataObject.setValue(Object x).   We could define this value as follows
>    a) if DataObject.getType() extends simple content, the value is the 
> value of the simple context.
>    b) if the DataObject.getType() does not extend simple content, then 
> unless the user does something, the DataObject.getValue() returns the 
> DataObject.
>    c) the user may call DataObject.setValue(null):  this sets xsi:nil to 

> true when serialized to XML.
>    d) unless the type extends simple context, it is an error to set the 
> "value" of a data object to anything other value (eg, to another data 
> object).
> 
> If we want to seperate the issues, then it seems odd to have 
> XMLHelper.isNil take a DataObject as a parameter.  Whether something is 
> nil seems not to be a character of the DataObject, but rather of the the 

> property where the data object is set.  That is, we can take an object 
> that is used as the value of a non-nillable property, and set it as the 
> value of a property that is nillable.  Or the other way around.  This 
sort 
> 
> 
> of leads to the XMLHelper.isNil(DataObject, Property) approach, with 
> corresponding setter and getter. I don't see the use case as being so 
> important that we need to add the additional convenience methods.
> 
> The suggesting to "project" to a DOM tree is interesting.  I'm wondering 

> how it differs from simply XMLHelper.save'ing to a DOMResult.  Frank, 
are 
> you imagining that the resulting DOM tree will be "live", that is, that 
> changes to the DOM tree will be tracked, and immediately visible in the 
> original SDO object?  This seems very ambitious!
> 
> Best Regards,
> Ron
> 
> 
> Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] 
> Gesendet: Freitag, 6. Juni 2008 22:25
> An: Frank Budinsky
> Cc: James Hart; sdo@lists.oasis-open.org
> Betreff: Re: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi Frank,
> 
> For the following example from your doc (section 2.7), I think there are 

> two options: 
> 
> <query>
>   <intRange min="1" xsi:nil="true"/>
> </query>
> 
> Option #1 - The property called "intRange" of type "IntegerRange" is set 

> and null. This option will not round trip, since the "min" property is 
> lost.
> Option #2 - The property called "intRange" is set to an instance of 
> "IntegerRange" and the "min" property is set to "1" and the "value" 
> property is set to null.  This option will round trip.
> 
> Then the problem is with the following use case?  Both of the options 
> below would marshal to the same XML document, but we would need to 
choose 
> one for the unmarshal operation.
> 
> <query>
>   <intRange xsi:nil="true"/>
> </query>
> 
> Option #1 - The property called "intRange" of type "IntegerRange" is set 

> and null.
> Option #2 - The property called "intRange" is set to an instance of 
> "IntegerRange" and the "min" property is unset, and value property is 
set 
> to null.  This option will round trip.
> 
> ---
> 
> I do not believe there is a need for the get/setNil operations.
> 
> ---
> 
> I see where you are going with the project to Node.class concept.  Our 
> EclipseLink implementation is built on top of our object-to-XML mapping 
> (MOXy) technology (which also supports JAXB).  We would offer the 
> corresponding functionality to our users through our implementation of 
the 
> 
> 
> JAXB Binder (which was designed for just this purpose).  The advantage 
of 
> the JAXB Binder approach is that it provides a specific scope in which 
the 
> 
> 
> objects and the DOM are linked.  If I use marshaller a new DOM is 
produced 
> 
> 
> for each marshal operation, but binder will return the one linked to my 
> object.
> 
> -Blaise
> 
> 
> Frank Budinsky wrote: 
> Hi James,
> 
> Thanks for the quick response. I'm not sure I understand this part:
> 
> 
> When we marshal out then it is a simple matter of checking if the
> property isSet() and isNullable() to know if we need to print out
> xsi:nil="true".
> 
> 
> In addition to knowing that the property isSet and isNullable, you need 
to 
> 
> 
> 
> know if the value is nil ... right? The case where the value is acutally 

> set to null is easy, but the case that I'm looking for a solution to is 
> that the value is an object where only attribute properties are set, 
while 
> 
> 
> 
> the element content should be xsi:nil. I think this may be an XML-only 
> concept.
> 
> The more I think about this, I'm starting to wonder if this is too 
> XML-specific to add to SDO? If we introduce an isNil method, like I 
> suggested, that only covers the read case. We would then want to start 
> thinking about adding some kind of setNil() method as well, e.g., 
> xmlHelper.setNil(myDO, "someProperty", true);
> 
> So, I'm starting to wonder if an Option 4 that allows XML users to fall 
> back to something like DOM and then just use it to look for the xsi:nil 
> attribute, would be a better approach.
> 
> For other reasons, I have been thinking about suggesting we add a new 
> method to DataObject that allows one to project a DataObject to other 
> interfaces:
> 
>     <T> T project(Class<T> targetClass);
> 
> I had been thinking that such a method could be used to project to a 
> Sequence "view" of the DataObject (and we could deprecate the 
getSequence 
> method):
> 
>     Sequence sequence = myDO.project(Sequence.class);
> 
> or it could be used to project to a static interface (instead of just 
> casting - this would allow implementation to use a different instance 
for 
> the static object):
> 
>     Company company = myDO.project(Company.class);
> 
> and now, I think this could be the way we allow XML users to work with 
> advanced XML features:
> 
>     Node node = myDO.project(Node.class);
> 
> What do others think about this suggestion and this issue in general?
> 
> Thanks,
> Frank.
> 
> 
> 
> 
> 
> "James Hart" <James.Hart@Roguewave.Com> 
> 06/04/2008 10:57 AM
> 
> To
> Frank Budinsky/Toronto/IBM@IBMCA, <sdo@lists.oasis-open.org>
> cc
> 
> Subject
> RE: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> 
> 
> 
> 
> 
> Our implementation has custom support for this already.  I'll describe
> what we do that seems to work well.
> 
> In our SDO implementation on our PropertyImpl we support a isNullable
> state which defaults to false. It also contains a isNullable() method
> that returns this state.  The state can only be set during construction,
> but it defaults to false.  On our Impl's for DataFactory and TypeManager
> all of our addProperty* methods have an additional method which includes
> a isNullable parameter so it can be told to create a nullable property.
> 
> Our XSDHelper when constructing types simply creates the property using
> the TypeImpl API for addProperty that also exposes the isNullable
> parameter.
> 
> When we marshal out then it is a simple matter of checking if the
> property isSet() and isNullable() to know if we need to print out
> xsi:nil="true".  Otherwise we can print out whatever the default value
> is.
> 
> I'd like to point out it doesn't matter in this case if the Property is
> has a type of DataObject or DataObjectType so it is more generic than
> the concept of xml's attributes, we just needed this concept to support
> these kind of xml documents.
> 
> Saying that I don't think we need a special isNil() method, that would
> just be icing ;)
> 
> I do think that the concept of data being "nill" or nullable for other
> data sets than xml is viable.  For example, a DB has nullable columns
> and have defaults vs. columns that have defaults and are not nullable
> much in the same fashion of nillable attributes in schema.  So I would
> prefer the benefits of making the concept nillable part of SDO's
> properties and not something that is only DAS dependant.
> 
>  I can also say option #2 works well because that is essentially what we
> do and it allows us to support these concepts in both our XSDHelper
> XMLHelper XMLDas and DBDas.  The biggest drawback is that it increases
> the size of the in memory for every single property which is a concern
> when having to support very large data sets, but I think that currently
> is an issue with all of the state information and could be trivialized
> and a responsibility  to solve as an implementation issue and not
> something that the spec has to solve.
> 
>  Thanks,
>    James
> 
> 
> 
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Sent: Tuesday, June 03, 2008 7:18 PM
> To: sdo@lists.oasis-open.org
> Subject: [sdo] XML Fidelity issue: xsi:nil with attributes
> 
> Hi Guys,
> 
> I'd like to start discussing some of the XML fidelity issues. The first 
> one, hopefully easy, is to come up with a way to handle nillable
> elements 
> with attributes. The problem is described in section 2.7 in this doc:
> 
> http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/26722/SDO_
> XML_Issues.doc
> 
> Here is my first thoughts on possible solutions:
> 
> Option 1: Add a helper method (to XMLHelper or maybe DataHelper if we 
> think this may not be an XML-only issue) to determine if a value is nil:
> 
> boolean isNil(Object value);
> 
> This method would return true if value == null or if value is a
> DataObject 
> with an xsi:nil tag. Users could use it something like this:
> 
> if (xmlHelper.isNil(myDO.get("someValue"))) {
>     // someValue is nil
> }
> 
> Option 2: We could have a method that takes a DataObject and a property 
> path as arguments to determine if a property is nil without actually 
> getting the value:
> 
> boolean isNil(DataObject object, String path);
> 
> if (xmlHelper.isNil(myDO, "someValue")) {
>     // someValue is nil
> }
> 
> If we go with this approach we would probably want 3 methods:
> 
> boolean isNil(DataObject object, String path);
> boolean isNil(DataObject object, Property property);
> boolean isNil(DataObject object, int index);
> 
> Option 3: Add the methods to DataObject:
> 
> boolean isNil(String path);
> boolean isNil(Property property);
> boolean isNil(int index);
> 
> if (myDO.isNil("someValue")) {
>     // someValue is nil
> }
> 
> This is nice and clean but would only make sense if we can think of
> other 
> data domains (other than XML) where the concept of nil (different from 
> null) applies.
> 
> Please let me know what you guys think about these suggestions, or if
> you 
> have any other ideas.
> 
> Thanks,
> Frank.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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.  You may a link to this group and 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]