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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

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

Subject: RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC


Now there's an incentive if ever I saw one!  :-)

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.


Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM>
Sent by: <oasis-charter-discuss@lists.oasis-open.org>

10/21/2011 10:28 AM

To
Patrick Durusau <patrick@durusau.net>, oasis-charter-discuss@lists.oasis-open.org
cc
Chet Ensign <chet.ensign@oasis-open.org>, tc-announce@lists.oasis-open.org, [email protected], Staff <[email protected]>, steve.g.jones@capgemini.com, [email protected], [email protected], ings@ca.ibm.com, [email protected], [email protected], "Patil, Sanjay" <sanjay.patil@sap.com>, [email protected], Dpalma@virtunomic.com, Paul Fremantle <[email protected]>, [email protected], thilinab@wso2.com, [email protected], [email protected], [email protected], steve.winkler@sap.com, "Probst, Richard" <[email protected]>, michael.schuster@sap.com, [email protected], [email protected], vsarathy@redhat.com, [email protected], [email protected], [email protected], ctrielof@redhat.com, [email protected], [email protected], thomas.spatzier@de.ibm.com, Mike Baskey/Poughkeepsie/IBM@IBMUS, [email protected], wayne.adams@emc.com, [email protected], [email protected], "Sundaresh, Chandrasekha" <Chandrasekha.Sundaresh@ca.com>, "Sijelmassi, Rachid" <Rachid.Sijelmassi@ca.com>, "Moscovich, Efraim" <Efraim.Moscovich@ca.com>, [email protected], "Lipton, Paul C" <Paul.Lipton@ca.com>, [email protected]
Subject
RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC





Patrick,

I will eat my hat if they get to OASIS Committee Spec in 9 months - and record it and put it on youtube. Dates like these are aspirational, common, and always missed!

Martin.

> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net]
> Sent: 20 October 2011 21:40
> To: oasis-charter-discuss@lists.oasis-open.org
> Cc: Chet Ensign; tc-announce@lists.oasis-open.org; [email protected]
> open.org; Staff; steve.g.jones@capgemini.com; [email protected];
> roland.wartenberg@citrix.com; [email protected]; [email protected];
> mlittle@redhat.com; Patil, Sanjay; [email protected];
> Dpalma@virtunomic.com; Paul Fremantle; [email protected]; [email protected];
> srinath@wso2.com; [email protected]; [email protected]; [email protected];
> Probst, Richard; michael.schuster@sap.com; [email protected];
> kevin.poulter@sap.com; [email protected]; [email protected];
> lutter@redhat.com; [email protected]; [email protected];
> Frank.Leymann@iaas.uni-stuttgart.de; [email protected];
> thomas.spatzier@de.ibm.com; [email protected]; [email protected];
> wayne.adams@emc.com; [email protected]; [email protected];
> Sundaresh, Chandrasekha; Sijelmassi, Rachid; Moscovich, Efraim;
> jani.anttila@capgemini.com; Lipton, Paul C; [email protected]
> Subject: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS
> Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>
> Chet,
>
> First, OASIS needs to get the mailing lists configured so you can post
> the list and thus replies will be to the list and not you.
>
> Second, I am troubled by the the language:
>
> > The TOSCA TC will provide the following set of deliverables:
> >
> > 1. A revised Topology and Orchestration Specification for Cloud
> > Applications, and associated XML Schema plus conformance statements
> > will be approved and completed by the TC within nine months of the
> > first TOSCA TC meeting.
> > 2. A set of sample Cloud Service Templates and related artifacts will
> > be approved and completed by the TC within nine months of the first
> > TOSCA TC meeting. These examples are non-normative, but can be used as
> > test cases for testing conformance of individual TOSCA implementations
> > as well as interoperability between multiple TOSCA implementations.
> > 3. Optionally, such other non-normative deliverables within the scope
> > listed in paragraphs 1-8  such as tutorials or presentations), as the
> > TC may elect, within nine months of the first TOSCA TC meeting.
> >
> > Maintenance:  Once the TC has completed work on a deliverable and it
> > has become an OASIS Standard, the TC will enter "maintenance mode" for
> > the deliverable.
> > The purpose of maintenance mode is to provide minor revisions to
> > previously adopted deliverables to clarify ambiguities,
> > inconsistencies and obvious errors. Maintenance mode is not intended
> > to enhance a deliverable or to extend its functionality.
>
> Apparently the proposers of this TC have some content in mind that is
> sufficient in their view to become both a Committee Specification as
> well as an OASIS Standard. That may or may not be the case.
>
> It is certainly *not the case* that proposers can set arbitrary
> deadlines for the completion of work that has yet to be seen by the
> OASIS members who will be called to vote upon it.
>
> I am well familiar with the "standards process is too slow" refrain,
> which rings false in light of 2 or 3 year development cycles for serious
> software. I am excluding vaporware from consideration.
>
> I am also aware that the "9-month to approval" content has not been
> disclosed and that is the subject of another thread. I won't repeat
> those concerns but I share them.
>
> Just in case the proposers are unfamiliar with OASIS, an *open*
> standards process doesn't have "gotcha" filing of documents, pre-set
> limits on discussion and revision, pre-determined approval and
> maintenance schedules and the like.
>
> Just as an aside to the TAB: Perhaps we need a 2-3 page - How Open
> Standards Develop type document that closes with common mis-steps like
> trying to force approval of not substantially revised proposals as
> "standards." There is a name for that sort of content but "standard"
> isn't one of them.
>
> Hope you are having a great day!
>
> Patrick
>
>
>
>
> On 10/20/2011 08:18 AM, Chet Ensign wrote:
> > To OASIS Members:
> >
> > A draft TC charter has been submitted to establish the OASIS Topology
> > and Orchestration Specification for Cloud Applications (TOSCA)
> > Technical Committee. In accordance with the OASIS TC Process Policy
> > section 2.2: (http://www.oasis-open.org/committees/process-2009-07-
> 30.php#formation)
> > the proposed charter is hereby submitted for comment. The comment
> > period shall remain open until 11:45 pm ET on 3 November 2011.
> >
> > OASIS maintains a mailing list for the purpose of submitting comments
> > on proposed charters. Any OASIS member may post to this list by
> > sending email to: oasis-charter-discuss@lists.oasis-open.org. All
> > messages will be publicly archived at:
> > http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members
> > who wish to receive emails must join the group by selecting "join
> > group" on the group home page:
> > http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
> > Employees of organizational members do not require primary
> > representative approval to subscribe to the oasis-charter-discuss
> > e-mail.
> >
> > A telephone conference will be held among the Convener, the OASIS TC
> > Administrator, and those proposers who wish to attend within four days
> > of the close of the comment period. The announcement and call-in
> > information will be noted on the OASIS Charter Discuss Group Calendar.
> >
> > We encourage member comment and ask that you note the name of the
> > proposed TC (TOSCA TC) in the subject line of your email message.
> >
> > ---
> >
> > PROPOSED CHARTER
> >
> > 1.a Name of the TC:
> > OASIS Topology and Orchestration Specification for Cloud Applications
> > (TOSCA) Technical Committee
> >
> >
> > 1.b Statement of Purpose:
> > The goal of the Topology and Orchestration Specification for Cloud
> > Applications (TOSCA) TC is to substantially enhance the portability of
> > cloud applications and the IT services that comprise them running on
> > complex software and hardware infrastructure.
> >
> > TOSCA will facilitate this goal by enabling the interoperable
> > description of application and infrastructure cloud services, the
> > relationships between parts of the service, and the operational
> > behavior of these services (e.g., deploy, patch, shutdown) independent
> > of the supplier creating the service, and any particular cloud
> > provider or hosting technology. TOSCA will also enable the association
> > of that higher-level operational behavior with cloud infrastructure
> > management.
> >
> > This capability will greatly facilitate much higher levels of cloud
> > service/solution portability without lock-in, including:
> >
> > *       Portable deployment to any compliant cloud
> > *       Easier migration of existing applications to the cloud
> > *       Flexible bursting (consumer choice)
> > *       Dynamic multi-cloud provider applications
> >
> > Ultimately, this will benefit the consumers, developers, and providers
> > of cloud-based solutions and provide an essential foundation for even
> > higher-level TOSCA-based vocabularies that could be focused on
> > specific solutions and domains.
> >
> >
> > 1.c Scope of Work:
> > The TOSCA TC intends to accept as one input the draft TOSCA
> > specification [1] provided by Capgemini, CA Technologies, Cisco,
> > Citrix, EMC, IBM, PwC, Red Hat, SAP, Software AG, Virtunomic, and
> > WSO2, as well as any subsequent input documents accepted by the TOSCA
> > TC. The TOSCA TC will use this draft TOSCA specification as a
> > foundation for further standardization of a basic set of concrete
> > components, relationships and properties (with extension mechanisms to
> > add additional components, relationships and properties). Further work
> > on specific vocabularies, based on these extension mechanisms, is out
> > of scope for this specification, but could begin in parallel with this
> > project, using the TOSCA naming syntax.
> >
> > The scope of the TOSCA TC's work is to produce specifications that
> > standardize the concepts as well as XML documents and XML Schema
> > renderings of the areas described below by further refinement and
> > finalization of the input document and any subsequent input documents
> > accepted by the TOSCA TC. The following items are specifically in
> > scope of the resulting TOSCA specification:
> >
> > 1. A language that provides the ability to specify a Service Template
> > that can define the topology (or structure) of a service and that can
> > utilize existing process modeling standards (especially BPMN 2.0) to
> > define orchestration (via "plans") that can invoke the manageability
> > behavior of cloud services.
> > 2. A syntax for naming component types, components, relationship
> > types, relationships, and properties, and for grouping of components.
> > 3. The ability to constrain the use of the various elements and their
> > properties that define the topology of a service.
> > 4. The ability to cross-reference Service Templates to enable
> > composition of services and to enable the management of instantiations
> > of a Service Template in heterogeneous environments.
> > 5. The ability to use virtual images as implementation artifacts for
> > parts of a Service Template.
> > 6. The ability to use application artifacts (e.g. JEE, ABAP, etc) as
> > deployment artifacts for parts of a Service Template.
> > 7. The ability to use other artifacts (e.g. EAR files, OVF files, SCA
> > components, etc) as deployment artifacts for parts of a Service
> > Template.
> > 8. The ability to annotate the various elements that define the
> > topology of a Service Template with policies that influence use of
> > instances of a Service Template. Such annotations could leverage a
> > wide range of policy languages (e.g. WS-Policy [2], KaoS [3], etc.).
> >
> > Compatibility:  There are no formal requirements for upward
> > compatibility. Nevertheless, the specification should be compatible
> > with existing business process modeling standards like BPMN 2.0 [4]
> > and WS-BPEL [5]. Furthermore, interfaces of component types should be
> > able to be expressed in a proper REST-style based on HTTP and
> > specified via WSDL 1.1, and allow for the use of scripts.
> >
> >
> > Out of Scope:  The following is a non-exhaustive list. It is provided
> > only for the sake of clarity. If some function, mechanism or feature
> > is not mentioned here, and it is not mentioned in the Scope of Work
> > section, then it will be deemed to be out of scope. The following
> > items are specifically out of scope of the TOSCA specification:
> >
> > 1. The definition of concrete cloud services, i.e. the definition of
> > concrete component types, relationship types, and topology templates.
> > However, standardization of a basic set of concrete component types,
> > relationship types and properties is intended to be enabled by this
> > work, and could begin in parallel with this project, with appropriate
> > coordination.
> > 2. The definition of concrete plans, i.e. the definition of plans in
> > any process modeling language like BPMN or BPEL.
> > 3. The definition of a language for defining plans (i.e. a new process
> > modeling language).
> > 4. The definition of concrete policies influencing the management and
> > use of instances of a Service Template.
> > 5. The emphasis of any particular single technology (e.g. hypervisor
> > virtualization) for the implementation of cloud services.
> > 6. The emphasis of any particular policy definition language or mechanism.
> > 7. The architecture of a service container used to instantiate service
> > definitions and manage such instances.
> > 8. The interface definitions of a service container.
> > 9. A graphical notation for modeling Service Templates.
> > 10. The definition of semantic models for cloud services.
> > 11. The specification of functional behavior as well as functional
> > composition of cloud services.
> >
> > Subsequent specifications may provide the Service Templates of
> > concrete cloud services. This will enable, for example, the creation
> > of catalogues of Service Templates in various application domains.
> >
> >
> > 1.d Deliverables
> > The TOSCA TC will provide the following set of deliverables:
> >
> > 1. A revised Topology and Orchestration Specification for Cloud
> > Applications, and associated XML Schema plus conformance statements
> > will be approved and completed by the TC within nine months of the
> > first TOSCA TC meeting.
> > 2. A set of sample Cloud Service Templates and related artifacts will
> > be approved and completed by the TC within nine months of the first
> > TOSCA TC meeting. These examples are non-normative, but can be used as
> > test cases for testing conformance of individual TOSCA implementations
> > as well as interoperability between multiple TOSCA implementations.
> > 3. Optionally, such other non-normative deliverables within the scope
> > listed in paragraphs 1-8  such as tutorials or presentations), as the
> > TC may elect, within nine months of the first TOSCA TC meeting.
> >
> > Maintenance:  Once the TC has completed work on a deliverable and it
> > has become an OASIS Standard, the TC will enter "maintenance mode" for
> > the deliverable.
> > The purpose of maintenance mode is to provide minor revisions to
> > previously adopted deliverables to clarify ambiguities,
> > inconsistencies and obvious errors. Maintenance mode is not intended
> > to enhance a deliverable or to extend its functionality.
> >
> > The TC will collect issues raised against the deliverables and
> > periodically process those issues. Issues that request or require new
> > or enhanced functionality shall be marked as enhancement requests and
> > set aside. Issues that result in the clarification or correction of
> > the deliverables shall be processed. The TC shall maintain a list of
> > these adopted clarifications and shall periodically create a new minor
> > revision of the deliverables including these updates. Periodically,
> > but at least once a year, the TC shall produce and vote upon a new
> > minor revision of the deliverables.
> >
> >
> > 1.e IPR Mode
> > This TC will operate under the "RF (Royalty Free) on Limited Terms"
> > IPR mode as defined in the OASIS Intellectual Property Rights (IPR)
> > Policy.
> >
> >
> > 1.f Anticipated Audience
> > The anticipated audience for this work includes:
> >
> > 1. Vendors and service providers offering products and/or services
> > designed to host or support cloud services, especially...
> >     a. Solutions used to model and create cloud services
> >     b. Solutions that support the execution of cloud services
> >     c. Solutions that manage cloud services
> >     d. Solutions designed to provide (parts of) cloud services as virtual
> images
> >     e. Solutions designed to deploy or manage cloud services across
> > multiple service providers
> > 2. Other specification authors that require cloud Service Templates
> > 3. Software architects who design, write, integrate and deploy cloud
> > services in a cloud environment as well as in a mix of cloud
> > environments and on-premise environments
> > 4. End users implementing solutions that require an interoperable,
> > composable solution using cloud services Language
> >
> >
> > 1.g Language:
> > The output documents will be written in (US) English.
> >
> >
> > References:
> > [1] Topology and Orchestration Specification for Cloud Applications,
> > Draft Specification, September 2011.
> > [2] Web Services Policy 1.5 - Framework, W3C Recommendation, available
> > via http://www.w3.org/TR/ws-policy/
> > [3] KAoS, Florida Institute for Human and Machine Cognition, available
> > via http://ontology.ihmc.us/index.html
> >   [4] OMG Business Process Model and Notation (BPMN) Version 2.0,
> > available via http://www.omg.org/spec/BPMN/2.0/
> > [5] OASIS Web Services Business Process Execution Language (WS-BPEL)
> > 2.0, available via
> > http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
> >
> >
> > ADDITIONAL INFORMATION:
> >
> > 2.a Identification of similar or applicable work:
> > The proposed "TOSCA TC" will be incorporating definitions and
> > terminologies from OASIS standards bodies as well as standards work
> > done by non-OASIS organizations. As stated in the charter, The TC will
> > use standard a standard from one non-OASIS organization and may choose
> > to use the works of other OASIS TCs and standards from non-OASIS
> > organizations, as it sees fit.  Liaisons may be established, and the
> > TC may agree to concurrent work items with other TCs and
> > organizations, within the scope defined here. Among other things, the
> > TC may establish liaisons with ISO JTC1 SC 38, the DMTF, and such
> > other standards organizations, as it may choose.
> >
> >
> > 2.b The date, time, and location of the first meeting:
> > The proposed "TOSCA TC" will hold the first official meeting on
> > December 8th, 2011 at 7:00am (PT) / 10:00am (ET) by telephone and will
> > use a free conference call service.
> >
> >
> > 2.c The projected on-going meeting schedule for the year:
> > The TC will meet weekly or as otherwise agreed upon by the members of
> > the technical committee.
> >
> >
> > 2.d The names, electronic mail addresses, and membership affiliations
> > of at least Minimum Membership who support this proposal:
> >
> > Steve Jones, steve.g.jones@capgemini.com (Capgemini)
> > Jani Anttila, jani.anttila@capgemini.com (Capgemini)
> >
> > Paul Lipton, paul.lipton@ca.com (CA Technologies)
> > Efraim Moscovich, Efraim.Moscovich@ca.com (CA Technologies)
> > Rachid Sijelmassi, Rachid.Sijelmassi@ca.com (CA Technologies)
> > Chandrasekha Sundaresh, Chandrasekha.Sundaresh@ca.com (CA Technologies)
> >
> > Naveen Joy, najoy@cisco.com (Cisco Systems)
> >
> > Roland Wartenberg, roland.wartenberg@citrix.com (Citrix Systems, Inc.)
> > Shishir Pardikar, Shishir.Pardikar@citrix.com (Citrix Systems, Inc.)
> >
> > Wayne Adams, wayne.adams@emc.com (EMC)
> >
> > Simon Moser, smoser@de.ibm.com (IBM)
> > Mike Baskey, mbaskey@us.ibm.com (IBM)
> > Thomas Spatzier, thomas.spatzier@de.ibm.com (IBM)
> > Gerd Breiter, GBREITER@de.ibm.com (IBM)
> > Frank Leymann, Frank.Leymann@iaas.uni-stuttgart.de (IBM)
> >
> > Dhiraj Pathak, PhD, dhiraj.pathak@us.pwc.com (PwC)
> >
> > Mark Little (Red Hat) mlittle@redhat.com - Primary Contact
> > Carl Trieloff (Red Hat) ctrielof@redhat.com - Secondary Contact
> > John Dunning (Red Hat) jdunning@redhat.com - Technical Contact
> > David Lutter (Red Hat) lutter@redhat.com - Technical Contact
> > Sherry Yu (Red Hat) syu@redhat.com - Technical Contact
> > Vijay Sarathy (Red Hat) vsarathy@redhat.com - Marketing Contact
> >
> > Steve Winkler, steve.winkler@sap.com, SAP
> > Richard Probst, richard.probst@sap.com, SAP
> > Michael Schuster, michael.schuster@sap.com, SAP
> > Allen Bannon, allen.bannon@sap.com, SAP
> > Kevin Poulter, kevin.poulter@sap.com, SAP
> >
> > Prasad Yendluri, Prasad.Yendluri@softwareag.com (Software AG)
> >
> > Derek Palma, Dpalma@virtunomic.com, (Virtunomic)
> >
> > Afkham Azeez, azeez@wso2.com (WSO2)
> > Thilina Buddhika, thilinab@wso2.com (WSO2)
> > Paul Fremantle, paul@wso2.com (WSO2)
> > Srinath Perera, srinath@wso2.com (WSO2)
> > Selvaratnam Uthaiyashankar, shankar@wso2.com (WSO2)
> > Sanjiva Weerawarana, sanjiva@wso2.com (WSO2)
> > Charith Wickramarachchi, charith@wso2.com (WSO2)
> >
> > 2.e Primary Representative Approval Statements:
> >
> > Steve Jones, steve.g.jones@capgemini.com
> > Global Director MDM, Capgemini
> > As Capgemini's Primary Representative, I approve the TOSCA TC Charter
> > and its goals of standardising the management and orchestration of
> > cloud solutions, and support our proposers (listed above) as a named
> > co-proposers.
> >
> > Nancy Cam-Winget, ncamwing@cisco.com
> > Distinguished Engineer, Cisco Systems, Inc
> > As Cisco Systems Primary Representative, I approve the TOSCA TC
> > Charter and its worthwhile goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Paul Lipton, paul.lipton@ca.com
> > VP, Industry Standards and Open Source, CA Technologies
> > As CA Technologies Primary Representative, I approve the TOSCA TC
> > Charter and its worthwhile goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Roland Wartenberg, roland.wartenberg@citrix.com Director, Strategic
> > Alliances, Citrix Systems Inc.
> > As Citrix Primary Representative, I approve the TOSCA TC Charter and
> > its worthwhile goals, and support our proposers (listed above) as a
> > named co-proposers.
> >
> > Rob Philpott, robert.philpott@emc.com
> > Senior Technologist, RSA division of EMC
> > As EMC's Primary Representative for OASIS, EMC is pleased with the
> > prospect of developing the TOSCA specifications under OASIS, and
> > approve the TOSCA TC Charter. I support our proposer as a named
> > co-proposer. Additionally, EMC plans to bring more representatives to
> > this project once this important new work is established within OASIS.
> >
> > Dave Ings, ings@ca.ibm.com
> > Emerging Software Standards
> > As IBM's primary OASIS rep, I approve the TOSCA TC Charter, and
> > endorse our proposers (listed above) as named co-proposers.
> >
> > Dhiraj Pathak, PhD, dhiraj.pathak@us.pwc.com
> > PricewaterhouseCoopers LLP
> >
> > Mark Little, mlittle@redhat.com
> > As the Red Hat's Primary Representative to OASIS, I approve the TOSCA
> > TC Charter and its worthwhile goals, and support our proposers (listed
> > below) as a named co-proposers.
> >
> > Sanjay Patil, sanjay.patil@sap.com
> > Standards Management&  Strategy, SAP AG
> > As SAP's Primary Representative for OASIS, I am excited with the
> > prospect of developing the TOSCA specifications under OASIS, and
> > approve the TOSCA TC Charter. I support our proposers (listed above)
> > as the named co-proposers.
> >
> > Prasad Yendluri, prasad.yendluri@softwareag.com
> > VP&  Deputy CTO
> > As Software AG's Primary Representative to OASIS, I approve the TOSCA
> > TC Charter and its stated goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Derek Palma, Dpalma@virtunomic.com
> > CTO Virtunomic Inc
> > As Virtunomic's Primary Representative for OASIS, I am excited with
> > the prospect of developing the TOSCA specifications under OASIS, and
> > approve the TOSCA TC Charter.
> >
> > Paul Fremantle, paul@wso2.com
> > As WSO2's primary representative to OASIS, fully support the proposed
> > TOSCA TC charter, and support our proposers (listed above) as named
> > co-proposers.
> >
> >
> > 2.f Convener:
> > Paul Lipton, CA Technologies
> >
> > 2.h Optional list of anticipated contributions:
> > The TOSCA TC intends to use as a foundation and input the draft TOSCA
> > specification [1] provided by Capgemini, CA Technologies, Cisco,
> > Citrix, EMC, IBM, PwC, Red Hat, SAP, Software AG, Virtunomic, and
> > WSO2, as well as any subsequent input documents accepted by the TOSCA
> > TC.
> >
>
>
> --
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
>
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: oasis-charter-discuss-unsubscribe@lists.oasis-
> open.org
> For additional commands, e-mail: oasis-charter-discuss-help@lists.oasis-
> open.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: oasis-charter-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: oasis-charter-discuss-help@lists.oasis-open.org

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