RE: [ciq] Identifiers in CIQ schemes

Very fruitful discussions! BTW, did you guyss manage to work on the implementation

considerations section of the document? I have not heard anything so far regarding this. I am

waiting on this to proceed further. Max, can you see how we have can separate namespaces for

Basic and Advanced (if possible) and how we can have provisions for an external namespace

or any URI for code lists if CIQ users want to use their own code lists of enumarated values for

----- Original Message -----
From: "Fulton Wilcox" <FULTON.WILCOX@COLTSNECKSOLUTIONS.COM>
To: "'Max Voskob'" <MAX.VOSKOB@PARADISE.NET.NZ>
Subject: RE: [ciq] Identifiers in CIQ schemes
Date: Tue, 15 Feb 2005 18:50:46 -0500

Max,

With respect to use within SAP (and like systems) of physical “address” apart from actually directing the mailing or shipping of things, it can be used in all sorts of ways – tax computations, business unit accountability, pricing, Capex planning, etc.

For such purposes, address information will typically not be used alone. As a hypothetical example, price y = f(x1, x2, x3) where x1 is contract number, x2 is order size, and x3 is “zone” – and “zone” perhaps being idiosyncratic. Typically the people who do the business deal will define “zone” (the contract domain) based on sets of postal codes or other CIQ-recognized conventions. However, “zone” in a pricing context may be really a proxy for cost level or shipping effort, so for example a product that has electricity or natural gas as a major cost component or is dependent on rail as a shipping mode might be “zoned” based on boundaries of the electric distribution network, gas pipeline or railroad network reach.

With respect to your category “data-matching,” I may be under-rating what activities and value propositions you would categorize under that term. To me, the use case is not whether people “match” data, but whether they move it into their own environments to make it their own.

My follow through point on “use cases” was to suggest demonstrating that a CIQ set of data could serve as the data source for populating and updating key master tables in SAP or Oracle, etc. (The payload data would of course have to undergo some mechanized transformation to be shoved into a relational database, etc).

For reference, below are two examples of a CIQ xml representation of a "customer” - a University of the Philippines example and an ABC Software Company example (I included only a snippet of the ABC Company XML, because the XML to represent the full organizational structure ran long).

Almost certainly there is a vendor using SAP to do business with the University of the Philippines College of Arts and Science. If the CIQ XML shown below for the College of Arts and Sciences provides the “right stuff” it can serve as the source of “truth” against which that vendor synchronizes the vendor’s corresponding SAP master data fields. (The sample of course is not complete because the University has other deans, Departments, etc.).

The ABC Systems Inc. example provides not only “data” as commonly understood, but also implicit workflow “knowledge.” For example, if a Federal Express delivery person has a package for the ABC Systems Inc. software tester, the example highlights both the tester’s boss and the tester’s boss’s boss, so it is clear-cut that those two people can also sign for a package addressed to the tester (presuming the CIQ organizational data has been imported and comes up on the delivery person’s screen).

As you know, there are more complex CIQ examples on the OASIS site that include customer data regarding the customer’s phones, email, education, credit cards, vehicles, etc., so I think that what is needed in terms of tags and other XML artifacts is all there.

Such use cases are duplex – i.e., not only is the question can you take CIQ data into an ERP, but does an ERP like SAP have the right content to publish data that fits the CIQ standards? Again, I presume the answer is yes, but a use case demo would be handy (and, it’s a big world out there, maybe someone has already started).

Fulton Wilcox

Colts Neck Solutions LLC

Office of the Dean

      College of Arts and Sciences

      University of the Philippines

      Diliman Quezon City

      4022 Philippines

-->

- <AddressDetails>

- <Country>

<CountryName>Philippines</CountryName>

- <Locality Type="City">

<LocalityName>Diliman Quezon City</LocalityName>

- <Premise Type="University">

<PremiseName>Uinversity of the Philippines</PremiseName>

- <SubPremise Type="College">

<SubPremiseName>College of Arts and Sciences</SubPremiseName>

- <SubPremise Type="Office">

<SubPremiseName>Office of the Dean</SubPremiseName>

</SubPremise>

</Premise>

</Locality>

</Country>

</AddressDetails>

- <!--

ABC Systems, Inc

23 Walter Street

Ann Arbour

MI 48086

Mr. Robin Smith  (A)

CEO

Mrs. Cathy Freeman, CIO (B)

Mr. John McDonald, CFO  (C)

Mr. Peter Craike, CTO (D)

   Mrs. Latha Srikant, Development Manager (G)

       Miss. Jenny Chang, Programmer (H)

       Miss. Carolyne Hastings, Programmer (I)

   Mr. James Scott, Tester (F)

   Mr. Rodney Matt, Technical Writer (E)

-->

- <RelationshipRecord>

- <Customer PartyType="Organisation">

- <NameDetails xmlns="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0">

- <OrganisationNameDetails>

<NameLine>ABC Systems, Inc</NameLine>

</OrganisationNameDetails>

</NameDetails>

- <AddressDetails xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">

- <AddressLines>

<AddressLine Type="Line 1">23 Walter Street</AddressLine>

<AddressLine Type="Line 2">Ann Arbour</AddressLine>

</AddressLines>

</AddressDetails>

</Customer>

- <InRelationshipWith RelationshipType="Organisation-Person">

- <Customer PartyType="Person">

- <NameDetails xmlns="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0">

- <PersonName>

<NameLine>Mr. Robin Smith</NameLine>

</PersonName>

</NameDetails>

- <InRelationshipWith RelationshipType="Person-Person">

- <Customer>

- <NameDetails xmlns="urn:oasis:names:tc:ciq:xsdschema:xNL:2.0" PartyType="Person">

- <PersonName>

<NameLine>Mrs. Cathy Freeman</NameLine>

</PersonName>

</NameDetails>

</Customer>

- <RelationshipInformation>

<RelationshipTitle>BOSS-SUBORDINATE</RelationshipTitle>

<RelationshipNature>REPORTING TO CEO</RelationshipNature>

</RelationshipInformation>

</InRelationshipWith>

-----Original Message-----
From: Max Voskob [mailto:max.voskob@paradise.net.nz]
Sent: Monday, February 14, 2005 11:40 PM
To: ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes

Fulton,

Just want to clarify I understood you correctly.

If they use the address not just for delivery, then is the actual address INFORMATION being used by

SAP?

E.g. the address is processed and they group them by town, suburb, proximity to a particular point

on the map or something?

If this is the case, then it is most likely to fall into either of:

2) Conversion to geocodes for further processing

3) Data matchning

Please, correct me if I'm wrong.

Cheers,

Max

-----Original Message-----

From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]

Sent: Tuesday, 15 February 2005 17:10

To: 'Max Voskob'; ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

Max,

They may include "postal" uses, but they also apply in situations in which everything is electronic

and the relationship does not involve physical delivery. There is a powerful relationship between

what CIQ has defined in address and "identity."

The logical relationships in a relational data base (e.g., that 25 SAP sold-to's are linked to a

given "group-to" for pricing) reflect identity "sets" conceptually built around tags within CIQ.

That is, a typical SAP "group-to" pricing entity represents the set of sold-tos that share a given

business unit and geographic values (and perhaps other entity/vale combinations), with these values

packaged in ciq-defined tags.

There are important potential synergies, because the more that adopting and maintaining ciq defined

data creates both "postal" value and "non-postal"

values, the more likely it is that the data will be properly maintained.

Although I tend not to focus on more consumer-oriented integration of enterprise and address data,

see below:

1. News: MasterCard Cashes in on Web Services

Deploying a Web-services-based platform to integrate location data with existing enterprise

applications has allowed MasterCard to offer services that provide additional opportunities for

customers to use their credit cards.

http://ct.enews.eweek.com/rd/cts?d=186-1656-6-81-222544-186135-0-0-0-1

Fulton Wilcox

Colts Neck Solutions LLC

-----Original Message-----

From: Max Voskob [mailto:max.voskob@paradise.net.nz]

Sent: Monday, February 14, 2005 12:24 PM

To: ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

Fulton,

What you describe are usage scenarios.

To me they look like "POSTAL DELIVERY" use case.

ShipTo

BillTo

SoldTo

Cheers,

Max

-----Original Message-----

From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]

Sent: Tuesday, 15 February 2005 04:34

To: 'Max Voskob'; ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

All:

With respect to use cases, perhaps my little matrix below helps. Note that fleshed out "use cases"

can serve two roles: 1) to validate the CIQ design, and 2) perhaps more importantly, to set the

stage for "selling" the design of CIQ. Note that both prioritization and scientific sampling suggest

that one does not have to be exhaustive in trying every use case, but it is helpful to have a

comprehensive overview in mind.

Below I have listed down the left what I term "entities," and I expressed these in terms of the

principal customer entities in SAP R/3 (and of course these entities are found, if in somewhat

different terms, in other ERPs, so I cite SAP merely as a benchmark.).

Also, I have shown across the top a list of terms of the roles/processes in which those entities may

be the actors, the subjects, or may interact. With respect to addresses, "physical" is certainly a

high priority, because it has to do with mailing, emergency services routing, etc. However, the

others are often very important, and "workflow" is of growing importance.

Physical Logical Business Relationship

Workflow Jurisdictional

"Entities"

Sold-to

Group-to

Ship-to

Bill-to

Payer

"Quasi-entities"

Contracts

Purchase orders

Licenses

Certifications

People (attention: Sam Smith)

Legal notice addressees

Etc.

In SAP, Sold-to is the lowest level customer entity - e.g., that can hold pricing, Ship-to is the

lowest level physical customer entity (and for many situations sold to and ship to are effectively

synonym entities), group-to is a specialized sold-to entity that can hold pricing and other data

relevant to multiple sold tos, Bill-to is the customer entity that receives the invoices (and with

outsourcing common, could be in another company and another country), and Payer is the entity that

issues the payment (again perhaps outsourced). My presumption (perhaps worth testing with some

friendly SAPites) is that CIQ has the "right stuff" (and more) for suitably defining these entities

in typical uses.

Typical is of course gradually escalating in complexity. If a major company (XYZ, inc.) using SAP

R/3 internally has to implement a new major, multi-country trading relationship with, say, Toyota,

the "use case" becomes whether CIQ has the "right stuff" to serve as the overarching template for

defining "Toyota" within the supplier's information infrastructure. There are of course two further

questions, - 1) given that CIQ probably has the "right stuff," will the IT practitioners involved

recognize that fact and figure how to match CIQ to SAP and vice versa, and

2) does SAP R/3 itself

have the right stuff to accommodate the CIQ templates and data (which of course will have to be

significantly torqued to go into SAP's relational database structures).

Points 2 and 3 have to do

with CIQ adoption - i.e., will practitioners even try to leverage CIQ and if so will they be

defeated by limitations of their IT vehicles?

Note that SAP's own architecture is significantly changing, but the present test is probably against

SAP R/3 "classic" (e.g. R/3 4.6c) as opposed to the new more componentized SAP's.

What I list as quasi-entities are from a CIQ aspect a mixture of physical and abstract entities. As

an example, in various jurisdictions one has to be licensed to do business and may also need special

certificates. The address to which the license pertains often need to be aligned with entities such

as sold-to-addresses. The licenses and certifications typically have both physical components (e.g.,

applying to 155 Highstreet, your town, your

country) and a legal entity component (XYZ silicon fabrication LTD).

For certain hazardous materials, the customer may have a permit that allows up to 10 kilograms of a

certain substance, and that limit may pertain to multiple ship-to's within a facility. Some

customers in part or in whole outsource tracking to the supplier, and in other contexts (vendor

managed

inventory) the supplier may need to incorporate customer entities (inventory holding points) into

the supplier's roster of "entities').

Contracts and PO's are particularly nasty use cases, primarily because the people creating them are

often entirely unaware of the difficulties they cause by their choice of entity "model" and

reference points. Therefore, pricing a transaction in conformance with a contract may require tests

based on physical, abstract (e.g., customer "business unit" or,even worse, supplier and customer

business unit) and perhaps date aspects (which might involve predicting arrival time if the price is

"when delivered").

Similarly, there are legal addresses for notices - in the U.S. that may mean sending notices of

pricing changes or whatever to some office in the State of Delaware even though neither buyer nor

sellers have any physical facilities in or even near Delaware.

CIQ clearly does not "own" all the questions and issues involved in exploiting the fruits of CIQs

labors. On the other hand, it may be that a bit of work to try out use cases will both avoid future

rework and set the stage for quicker adoption.

Fulton Wilcox

Colts Neck Solutions LLC

Colts Neck, New Jersey USA 07722

-----Original Message-----

From: Max Voskob [mailto:max.voskob@paradise.net.nz]

Sent: Sunday, February 13, 2005 9:58 PM

To: ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

Colin,

I think even if the usage scenarios are numerous they can be nicely generalised to 2 or 3 use cases.

1) Attending an address (postal delivery, fire engine, etc.)

2) Conversion to geocodes for further processing

3) Data matchning

Can you add any other use cases that stand out?

Cheers,

Max

-----Original Message-----

From: Colin.Wallis@ssc.govt.nz [mailto:Colin.Wallis@ssc.govt.nz]

Sent: Monday, 14 February 2005 14:57

To: max.voskob@paradise.net.nz; ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

Quite correct Max...

When you talk to emergency services, the local council/city hall, the courier company, the Post

Office, the land registry..they all have different needs and uses. While we could get

representative usage scenarios, they will vary from country to country. It would be a big ask to do

a 100% "one size fits all" on this. Great if we can even get close though.

Cheers

Colin

-----Original Message-----

From: Max Voskob [mailto:max.voskob@paradise.net.nz]

Sent: Saturday, 12 February 2005 8:47 a.m.

To: ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

I started some work on the test cases back in 2004, but then stopped due to a lack of support and

information.

UPU provides only very simple addresses for all countries. If we followed that then xNAL would have

~ 10 elements at most.

I also attempted to write requirements for xNAL, but there was not much of a discussion around them.

I fully support the idea that a standard should be fit for the purpose and should not go beyond that

to keep it all simple.

Addresses have many various usage scenarios. Those scenarios require different level of

detailisation and presentation.

It would be good to formalise the scenarios and then try to compile a diverse set of test addresses

from all over the world.

Cheers,

Max

-----Original Message-----

From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]

Sent: Saturday, 12 February 2005 07:52

To: 'John D. Putman'; 'David Webber (XML)'; colin.wallis@ssc.govt.nz

Cc: 'Max Voskob'; ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

All:

Are there formal "use cases" to do scenario-testing of CIQ's products?

Success is "fitness for intended purpose(s)" - i.e., that the XML artifacts defined, if properly

populated with payload content, meet the envisioned needs.

As an observer, I recall several use cases being cited - feeding appropriate data to postal

delivery, similarly feeding private delivery routing processes (such as Fedex or freight common

carrier) and supporting marketing and other demographic studies. Previously, I injected the notion -

not exactly a use case - that there be a realistic integration scenario with ERP's such as SAP and

other business systems.

Are you already at the point of success with respect to those use case scenarios?

Fulton Wilcox

Colts Neck Solutions LLC

-----Original Message-----

From: John D. Putman [mailto:jdputman@scanningtech.fedex.com]

Sent: Friday, February 11, 2005 1:25 PM

To: David Webber (XML); John D. Putman;

fulton.wilcox@coltsnecksolutions.com; colin.wallis@ssc.govt.nz

Cc: 'Max Voskob'; ciq@lists.oasis-open.org

Subject: RE: [ciq] Identifiers in CIQ schemes

I will only say that we have and are "trying it" and have and are finding that the conjunction of

address and geocodes is better than assuming that geocode provides a unique key and "good enough"

location identifier. But that IS due to our paramount needs (for various operational and customer

service purposes) to not falsely or imprecisely identify a location - to either our couriers OR

customers. If one doesn't have such stringent needs, then you are probably right.

Thank you,

David Putman

-----Original Message-----

From: David Webber (XML) [mailto:david@drrw.info]

Sent: Friday, February 11, 2005 12:16 PM

To: John D. Putman; fulton.wilcox@coltsnecksolutions.com;

colin.wallis@ssc.govt.nz

Cc: 'Max Voskob'; ciq@lists.oasis-open.org

Subject: Re: [ciq] Identifiers in CIQ schemes

John,

No doubt! I never said it was perfect ; -)

But is it close enough for government work, mostly?

And - more to the point - seems to be about the only alternative right now...

That's why I was suggesting the GPS+five - since then you have a way of avoiding the same GPS

referencing 2,000 occupants of some high-rise tower block! But the GPS on its own should get you

outside the twin towers - then you can use the +five bit to figure out which tower - and which

floor, etc.

----- Original Message -----

From: "John D. Putman" <jdputman@scanningtech.fedex.com>

To: "David Webber (XML)" <david@drrw.info>; <fulton.wilcox@coltsnecksolutions.com>;

<colin.wallis@ssc.govt.nz>

Cc: "'Max Voskob'" <max.voskob@paradise.net.nz>; <ciq@lists.oasis-open.org>

Sent: Friday, February 11, 2005 11:36 AM

Subject: RE: [ciq] Identifiers in CIQ schemes

> Unfortunately, more than God is involved in GPS coordinates as

> mentioned

(as

> a referent for a recipient and/or address those DO change). The below

> is extracted from an analysis done to compare addresses and geocodes

> (full analysis attached) and covers several other aspects of the

> actual

real-world

> imprecision of geocodes and their variability. This makes geocode as

> an

> key susceptible to some problems and update requirements.

> Briefly -

> o Geocodes as they relate to address/location are sometimes "munges"

> ("best guess" calculations!).

> o Geocodes as they relate to a building, recipient, or delivery points

> for those DO REQUIRE updates!

> o Geocodes may not be precise enough ("munges"), OR their precision

> may not be evident to / easily applied by a user - for instance, a

delivery

> courier (not even if supplied with a GPS unit)!

> o Geocodes are NOT always equivalent to, do NOT always "contain" or

> "mark", or do NOT always adequately identify an address/location OR a

> recipient/customer.

> o Addresses can suffer similar problems -

> + No streets, only street names, or street range "munges" can

> occur in reference data.

> + Addresses and their elements are often updated.

> + Entry doors OR delivery docks to the SAME large building can

> be on multiple streets OR at non-street locations (alleys, "back

> lots", or warehouses / delivery "yards").

> + Addresses can also REQUIRE additional recipient related

> information.

> + Some postally valid addresses can be location opaque or

> NON-SPECIFIC! AND there are some addresses that are NOT represented

> in reference data (sometimes NOT in any data!).

> o As a result, address and geocodes may be complementary to each

> other; BUT

> + They should NOT be viewed as either reducible to or

> "subservient" to the other.

> + Certain recipient related data may be required over and

> above BOTH geocode and address.

> + Standards bodies recognize and agree that recipient data,

> primary address data, and geocode data are EITHER separate but

complementary

> domains OR should all be considered attributes or types of ADDRESS.

> + Geocodes ARE good for "getting close" AND recognizing likely

> co-location / closeness.

> + Addresses ARE good for easily user applicable referents and

> recipient directed delivery.

> + Geocode and address complementary use IS STILL superior to

> abstract "unique" keys for a many purposes - getting to an

address/location

> chief among those.

> o Generally, there ARE "HOLES" in almost any schema - address and

> geocodes included, with regard to their "real world" referents and the

> schemas themselves. These can be and ARE caused by

> + "illogical" or inconsistent "real-world" conditions /

> decisions,

> + update anomalies,

> + imprecision in identification,

> + outright mistakes,

> + actual lack of consistent or complete data.

> Thank you,

> David Putman

> -----Original Message-----

> From: David Webber (XML) [mailto:david@drrw.info]

> Sent: Friday, February 11, 2005 9:49 AM

> To: fulton.wilcox@coltsnecksolutions.com; colin.wallis@ssc.govt.nz

> Cc: 'Max Voskob'; ciq@lists.oasis-open.org

> Subject: Re: [ciq] Identifiers in CIQ schemes

> Fulton,

> I suggest using the GPS coordinates.

> Only God has control over how those get assigned...

> But you would have to separate the owner entity ID from the GPS ID -

> because people and companies move.

> And you do need a system for labelling large tall buildings to make

> the GPS + five or similar - unique to a location inside it!

> DW

> ----- Original Message -----

> From: "Fulton Wilcox" <fulton.wilcox@coltsnecksolutions.com>

> To: <colin.wallis@ssc.govt.nz>

> Cc: "'Max Voskob'" <max.voskob@paradise.net.nz>;

<ciq@lists.oasis-open.org>

> Sent: Thursday, February 10, 2005 10:15 PM

> Subject: RE: [ciq] Identifiers in CIQ schemes

> > Colin,

> >

> > Giving every address what amounts to a serial number sounds harmless

> except

> > that doing so is quite a bit of work.

> >

> > Perhaps one question to be addressed (no pun intended) is what

> > happens

> over

> > time? In the U.S., the postal service reorganizes ZIP codes for

> > locales

> that

> > are experiencing rapid growth. Companies buy and sell each other and

> > properties are subdivided or sometimes reunified. There are

> > short-lived addresses such as PO Boxes and "care/of" arrangements.

> > Addresses are

> highly

> > perishable.

> >

> > To make serialization useful, would you maintain successor and

predecessor

> > tables of all these changes? How would you propagate and retire

> > serial numbers across impacted databases?

> >

> > In return for this work, what is the payback?

> >

> > Fulton Wilcox

> > Colts Neck Solutions LLC

> >

> > -----Original Message-----

> > From: Max Voskob [mailto:max.voskob@paradise.net.nz]

> > Sent: Thursday, February 10, 2005 9:36 PM

> > To: colin.wallis@ssc.govt.nz; ciq@lists.oasis-open.org

> > Subject: RE: [ciq] Identifiers in CIQ schemes

> >

> > Hi Colin,

> >

> > In fact, NZ xNAL already has the ability to store ID for almost

> > anything

> and

> > use IDs instead of the actual address elements.

> >

> > Shared IDs are good when there is some aurotitave source of them.

> > There is no problem in assigning an ID to an address or location or

> > just

> > geographical name. The problem starts when you get the ID and want

> > to

know

> > what it means.

> >

> > The infrastructure needed to convert addresses into IDs and vice

> > versa

> might

> > be a show stopper.

> >

> > E.g. IDs can be sourced from LINZ BDE, but again, the infrastructure

> > to

> > just that is undefined.

> >

> > Would be interesting to know what your thoughts are.

> >

> > Cheers,

> > Max

> >

> > -----Original Message-----

> > From: colin.wallis@ssc.govt.nz [mailto:colin.wallis@ssc.govt.nz]

> > Sent: Friday, 11 February 2005 15:11

> > To: ciq@lists.oasis-open.org

> > Subject: [ciq] Identifiers in CIQ schemes

> >

> > Dear TC

> >

> > We have been having some debate here in NZ Government circles about

> > the

> need

> > to develop a unique identifier for each address. This would be in

> addition

> > to using, say, Customer ID in xCIL. This idea is to be able to link

> > the various types of address (physical, geospatial, emergency,

> > rural) held

> > government through the use of an id which all agencies can map back

> > to

> their

> > own records. We would also need to validate that with fields like:

> authors

> > name, last updated date and reason for update. There are several

> > issues around this but a key one, is how we might handle it in XML

> > address

files.

> > 1) Should we consider an address identifier for future releases?

> > 2) Should this be part of the actual xAL address file or remain

> > outside

> it?

> >

> > What re-ignited my thinking on this was this release from W3C:

> > http://xml.coverpages.org/ni2005-02-09-a.html

> >

> > To unsubscribe from this mailing list (and be removed from the

> > roster of

> the

> > OASIS TC), go to

> >

http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php

> > .

> >

> > To unsubscribe from this mailing list (and be removed from the

> > roster of

> the OASIS TC), go to

http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php

> .

> >

> To unsubscribe from this mailing list (and be removed from the roster

> of

the

> OASIS TC), go to

http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php

> .

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to