[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-cap-profiles] Specification Profiles, ApplicationProfiles, Layers...
On Sat, 10 Jan 2009, Rex Brooks wrote:
> Thanks Robin,
>
> I'd really like to get "ISO/IEC TR 10000-1:1998 Information technology -
> Framework and taxonomy
> of International Standardized Profiles - Part 1: General principles and
> documentation framework"
>
> It is cited in OGC 3.1 Section 22 Profiles. So far, I have found the OGC
> material very helpful.
>
> Cheers,
> Rex
ISO/IEC TR 10000 (1988)
Parts 1-3 are available from the collection of ISO Freely Available Standards,
as well as from the ISO Store (ca. $226 USD). Your choice. ;-)
I here provide bibliographic information and an unofficial excerpt from Part 1
(please see the complete ISO text for details, as the excerpt by itself
may be misleading).
==================================================================
I. ISO/IEC TR 10000 from the ISO Store (CHF 252, == USD $226)
==================================================================
ISO/IEC TR 10000-1:1998
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 1: General principles and
documentation framework
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30726
Cost: CHF 80,00
ISO/IEC TR 10000-2:1998
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 2: Principles and Taxonomy for OSI
Profiles
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30728
Cost: CHF 106,00
ISO/IEC TR 10000-3:1998
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 3: Principles and Taxonomy for
Open System Environment Profiles
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30727
Cost: CHF 66,00
==================================================================
II. ISO/IEC TR 10000 from ISO's Freely Available Standards
==================================================================
Freely Available ISO/IEC Standards
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
==================================================================
Bibliographic Information and Excerpt for ISO/IEC TR 10000-1 (Part 1)
==================================================================
ISO/IEC TR 10000-1:1998
Fourth Edition
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 1: General principles and documentation
framework. From JTC1. Technical Report. 1998-11-01. 18 pages.
Reference number: ISO/IEC TR 10000-1:1998(E)
Copyright (c) ISO/IEC 1998.
http://standards.iso.org/ittf/PubliclyAvailableStandards/c030726_ISO_IEC_TR_10000-1_1998(E).zip
ISO/IEC TR 10000-1, which is a Technical Report of type 3, was
prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology. This fourth edition cancels and replaces the third
edition (ISO/IEC TR 10000-1:1995), which has been technically
revised. ISO/IEC TR 10000 consists of the following parts, under
the general title "Information technology -- Framework and taxonomy
of International Standardized Profiles":
* Part 1: General principles and documentation framework
* Part 2: Principles and Taxonomy for OSI Profiles
* Part 3: Principles and Taxonomy for Open System Environment Profiles
* Other parts to be defined as necessary.
Introduction
The context of Functional Standardization is one part of the overall
field of IT standardization activities covering:
* Base Standards, which define fundamentals and generalized procedures.
They provide an infrastructure that can be used by a variety of
applications, each of which can make its own selection from the
options offered by them.
* Profiles, which define conforming subsets or combinations of base
standards used to provide specific functions. Profiles identify the
use of particular options available in the base standards, and provide
a basis for the development of uniform, internationally recognized,
conformance tests.
* Registration Mechanisms, which provide the means to specify detailed
parameterization within the framework of the base standards or
profiles.
Within ISO/IEC JTC 1, the process of Functional Standardization is
concerned with the methodology of defining profiles, and their
publication in documents called "International Standardized Profiles"
(ISPs) in accordance with procedures contained in the Directives of
JTC 1. The scope of Information Technology standardization to which
this process is being applied is that which corresponds to the
generally understood, but loosely defined, concept of "Open Systems".
The objective is to facilitate the specification of IT systems
characterized by a high degree of interoperability and portability
of their components.
Scope
This part of ISO/IEC TR 10000 defines the concept of profiles, and
the way in which they are documented in International Standardized
Profiles. It gives guidance to organizations making proposals for
Draft International Standardized Profiles on the nature and content
of the documents they are producing.
This part of ISO/IEC TR 10000 outlines concepts of profiles and
taxonomies (or Classification Schemes), and the format and content
of ISPs. Annex A gives details of the format and the content of
ISPs as required by ISO/IEC JTC 1.
ISO/IEC TR 10000-2 provides principles and a classification scheme
for OSI profiles which may be or have been submitted for ratification
as International Standardized Profiles.
NOTE: These OSI profiles specify OSI base standards, and those base
standards concerned with interchange formats and data representation
which are expected to be used in conjunction with them.
ISO/IEC TR 10000-3 provides the context for functional standardization
in support of Open System Environments (OSE), and principles and a
classification scheme for OSE profiles which may be or have been
submitted for ratification as International Standardized Profiles.
It outlines the basic OSE objectives and concepts, and defines an
approach and format for OSE profiles specified by International
Standardized Profiles and, along with this part of ISO/IEC TR 10000,
gives guidance to organizations making proposals for Draft ISPs on
the nature and content of the documents they produce.
Part 2 and Part 3 may be extended for OSI and OSE profiles respectively
and further parts of ISO/IEC TR 10000 may be developed to define other
classes of profiles.
ISO/IEC TR 10000 is applicable to all International Standardized
Profiles of ISO and IEC. Its primary focus is the area of competence
of ISO/IEC JTC 1, but by mutual agreement with JTC 1, other Technical
Committees may undertake similar functional standardization activities
leading to the inclusion of additional material in this Technical
Report.
[Definition]: "Profile: A set of one or more base standards and/or
ISPs, and, where applicable, the identification of chosen classes,
conforming subsets, options and parameters of those base standards,
or ISPs necessary to accomplish a particular function."
5. Purpose of profiles
Profiles define combinations of base standards or other profiles
for the purpose of:
* identifying the standards and ISPs, together with appropriate
classes, conforming subsets, options and parameters, which are
necessary to accomplish identified functions (e.g. interoperability)
or to support a class of applications (e.g. Transaction Processing
applications)
* providing a scheme of referencing the various uses of standards
and ISPs which is meaningful to both users and suppliers in
response to a systematic identification and analysis of user
requirements
* providing a means to enhance the availability for procurement of
consistent implementations of functionally defined groups of
standards and ISPs, which are expected to be the major components
of real IT systems, and which realise the intentions of the
corresponding reference models or frameworks with which the
standards are associated
* promoting uniformity in the development of conformance tests for
IT systems that implement the functions associated with the
profiles
Underlying all these purposes is the assumption that there exists
a requirement for the definition, standardization, implementation,
and testing of such a profile. The processes employed shall therefore
include the identification, recording, and monitoring of such
requirements, as expressed by the eventual users of the profile...
[******* please see the complete/official ISO text; the excerpt
above is in no way official or authoritative **********]
==================================================================
Bibliographic Information for ISO/IEC TR 10000-2 (Part 2)
==================================================================
ISO/IEC TR 10000-2:1998
Fifth Edition
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 2: Principles and Taxonomy for OSI
Profiles. From JTC1. Technical Report. 1998-11-01. 30 pages.
Online download (free):
http://standards.iso.org/ittf/PubliclyAvailableStandards/c030728_ISO_IEC_TR_10000-2_1998(E).zip
==================================================================
Bibliographic Information for ISO/IEC TR 10000-3 (Part 3)
==================================================================
ISO/IEC TR 10000-3:1998
Second Edition
Information technology -- Framework and taxonomy of International
Standardized Profiles -- Part 3: Principles and Taxonomy for Open
System Environment Profiles. From JTC1. Technical Report.
1998-11-01. 18 pages.
Online download (free):
http://standards.iso.org/ittf/PubliclyAvailableStandards/c030727_ISO_IEC_TR_10000-3_1998(E).zip
- Cheers,
Robin
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
----------
>
> At 3:43 PM -0500 1/10/09, Robin Cover wrote:
>> When I spotted the conversation about (definition of) "profiles" on the
>> EM CAP Profiles SC List [1], I sent Rex a brief note about WS-I, OGC,
>> DCMI, and (? IIRC) some other SSO arenas in which I'd spotted interesting
>> profile work.
>>
>> Here are a few references that may be of interest. I understand that the
>> topic (generally) has now been forwarded to the TAB for consideration.
>>
>> Examples:
>>
>> * UML Profiles
>> * Dublin Core Metadata Initiative (DCMI) Application Profiles
>> * Open Geospatial Consortium (OGC) Profiles and Application Profiles
>>
>> --------------------------------------------------------------------------
>> UML Profiles
>> --------------------------------------------------------------------------
>>
>> "UML Profiles are subsets of UML tailored for specific purposes"
>>
>> UML Profiles tailor the language to specific areas -- some for
>> business modeling; others for particular technologies. All of
>> our standard profiles are available from our Profiles Catalog at
>> http://www.omg.org/technology/documents/profile_catalog.htm
>> You'll find these Profiles:
>>
>> * Platform Independent Model (PIM) & Platform Specific Model
>> (PSM) for Software Radio Components (also referred to as
>> UML Profile for Software Radio)
>> * UML Profile for CORBA and CORBA Component Model (CCM)
>> * UML Profile for Enterprise Application Integration (EAI)
>> * UML Profile for Enterprise Distributed Object Computing (EDOC)
>> * UML Profile for Modeling QoS and Fault Tolerance Characteristics
>> and Mechanisms
>> * UML Profile for Schedulability, Performance and Time
>> * UML Profile for System on a Chip (SoC)
>> * UML Profile for Systems Engineering (SysML)
>> * UML Testing Profile
>>
>>
>> === 13 Core::Profiles ===
>> http://www.omg.org/docs/ptc/08-05-04.pdf
>>
>> The Profiles package contains mechanisms that allow metaclasses
>> from existing metamodels to be extended to adapt them for different
>> purposes. This includes the ability to tailor the UML metamodel
>> for different platforms (such as J2EE or .NET) or domains
>> (such as real-time or business process modeling). The profiles
>> mechanism is consistent with the OMG Meta Object Facility (MOF).
>>
>> === Extensibility ===
>>
>> The profiles mechanism is not a first-class extension mechanism
>> (i.e., it does not allow for modifying existing metamodels).
>> Rather, the intention of profiles is to give a straightforward
>> mechanism for adapting an existing metamodel with constructs that
>> are specific to a particular domain, platform, or method. Each
>> such adaptation is grouped in a profile. It is not possible to
>> take away any of the constraints that apply to a metamodel such
>> as UML using a profile, but it is possible to add new constraints
>> that are specific to the profile. The only other restrictions
>> are those inherent in the profiles mechanism; there is nothing
>> else that is intended to limit the way in which a metamodel is
>> customized.
>>
>> First-class extensibility is handled through MOF, where there are
>> no restrictions on what you are allowed to do with a metamodel:
>> you can add and remove metaclasses and relationships as you find
>> necessary. Of course, it is then possible to impose methodology
>> restrictions that you are not allowed to modify existing
>> metamodels, but only extend them. In this case, the mechanisms
>> for first-class extensibility and profiles start coalescing.
>> There are several reasons why you may want to customize a metamodel:
>>
>> * Give a terminology that is adapted to a particular platform or
>> domain (such as capturing EJB terminology like home interfaces,
>> enterprise java beans, and archives).
>> * Give a syntax for constructs that do not have a notation
>> (such as in the case of actions).
>> * Give a different notation for already existing symbols (such as
>> being able to use a picture of a computer instead of the
>> ordinary node symbol to represent a computer in a network).
>> * Add semantics that is left unspecified in the metamodel (such as
>> how to deal with priority when receiving signals in a
>> state machine).
>> * Add semantics that does not exist in the metamodel (such as
>> defining a timer, clock, or continuous time).
>> * Add constraints that restrict the way you may use the metamodel
>> and its constructs (such as disallowing actions from
>> being able to execute in parallel within a single transition).
>>
>> === Profiles History and design requirements ===
>>
>> The [UML] Profile mechanism has been specifically defined for
>> providing a lightweight extension mechanism to the UML standard.
>> In UML 1.1, stereotypes and tagged values were used as string-based
>> extensions that could be attached to UML model elements in a
>> flexible way. In subsequent revisions of UML, the notion of a
>> Profile was defined in order to provide more structure and
>> precision to the definition of Stereotypes and Tagged values. The
>> UML2.0 infrastructure and superstructure specifications have
>> carried this further, by defining it as a specific meta-modeling
>> technique. Stereotypes are specific metaclasses, tagged values are
>> standard metaattributes, and profiles are specific kinds of packages.
>>
>> The following requirements have driven the definition of profile
>> semantics from inception:
>>
>> 1. A profile must provide mechanisms for specializing a reference
>> metamodel (such as a set of UML packages) in such a way that
>> the specialized semantics do not contradict the semantics of
>> the reference metamodel. That is, profile constraints may
>> typically define well-formedness rules that are more constraining
>> (but consistent with) those specified by the reference metamodel.
>>
>> 2. It must be possible to interchange profiles between tools,
>> together with models to which they have been applied, by
>> using the UML XMI interchange mechanisms. A profile must
>> therefore be defined as an interchangeable UML model. In addition
>> to exchanging profiles together with models between tools,
>> profile application should also be definable 'by reference' (e.g.,
>> 'import by name'); that is, a profile does not need to be
>> interchanged if it is already present in the importing tool.
>>
>> 3. A profile must be able to reference domain-specific UML libraries
>> where certain model elements are pre-defined.
>>
>> 4. It must be possible to specify which profiles are being applied to
>> a given Package (or any specializations of that concept). This is
>> particularly useful during model interchange so that an importing
>> environment can interpret a model correctly.
>>
>> 5. It should be possible to define a UML extension that combines
>> profiles and model libraries (including template libraries) into
>> a single logical unit. However, within such a unit, for
>> definitional clarity and for ease of interchange (e.g.,
>> 'reference by name'), it should still be possible to keep the
>> libraries and the profiles distinct from each other.
>>
>> 6. A profile should be able to specialize the semantics of standard
>> UML metamodel elements. For example, in a model with the profile
>> 'Java model,' generalization of classes should be able to be
>> restricted to single inheritance without having to explicitly
>> assign a stereotype 'Java class' to each and every class instance.
>>
>> --------------------------------------------------------------------------
>> Dublin Core Metadata Initiative (DCMI) Application Profiles
>> --------------------------------------------------------------------------
>>
>> http://xml.coverpages.org/newsletter/news2009-01-05.html#cite4
>> http://dublincore.org/documents/2009/01/05/profile-review-criteria/
>> A new publication by the Dublin Core Metadata Initiative (DCMI)
>> Usage Board presents guidelines articulating the criteria by
>> which the DCMI Usage Board reviews an Application Profile. As of
>> March 2008, the main points of reference for these review criteria
>> are [...]
>>
>> http://dublincore.org/documents/2008/01/14/singapore-framework/
>> Singapore Framework for Dublin Core Application Profiles
>>
>> http://dublincore.org/documents/2007/06/04/abstract-model/
>> DCMI Abstract Model
>>
>> http://dublincore.org/documents/2008/03/31/dc-dsp/
>> Description Set Profile Specification
>>
>> http://dublincore.org/groups/collections/collection-application-profile/2007-03-09/
>> Dublin Core Collections Application Profile
>>
>> http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile
>> Eprints Application Profile
>>
>> --------------------------------------------------------------------------
>> Open Geospatial Consortium (OGC) Profilea and Application Profiles
>> --------------------------------------------------------------------------
>>
>> OGC Specification Profiles
>> http://www.opengeospatial.org/standards/profile
>>
>> The OGC Standards and Specifications
>> http://www.opengeospatial.org/standards/orm
>> OpenGIS Implementation Standards are of five types, three of which
>> are Profile, Application Profile, and Application Schema... In
>> the OGC, a GML profile is a restricted subset of the full GML standard.
>>
>> "The requirements of an application schema determine the XML Schema
>> components from the GML schema to be included in a GML profile. GML
>> defines a variety of conformance classes that apply depending upon
>> the content of a specific profile..."
>>
>> "GML Application Schemas: Designers of GML application schemas may
>> extend or restrict the types defined in the GML schema to define
>> appropriate types for an application domain. GML application
>> schemas use applicable GML schema components, either directly or
>> by specialization, and are valid in accordance with the rules for
>> XML Schema..."
>>
>> Schemas and Profiles - What's the Difference?
>> Ron Lake: Lots of discussion has taken place as to the role of GML
>> Application Schemas and GML profiles and a lot of this discussion
>> has been misleading as the two items are often confused with one
>> another...
>> http://geoweb.blog.com/419886/
>>
>> http://xml.coverpages.org/Reed-OGC-200701.html
>> "in the application layer, a common characteristic is that relatively
>> simple standards can be developed and deployed that are profiles
>> or application schemas of other, more "complex" standards such as
>> GML."
>>
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00002.html
>>
>> OGC Releases GML Simple Features Profile Specification for Review
>> http://xml.coverpages.org/ni2005-07-07-a.html
>>
>> "EDXL-HAVE - Conformance Statement" (Carl Reed)
>>
>> By way of background, the OGC has had compliance testing for a
>> number of our standards for many years. We have recently upgraded
>> the compliance testing engine (open source) and our members have
>> developed a Compliance Assertion Language (more on this later). We
>> have recently added tests for 6 existing OGC standards and some
>> profiles of those standards, such as GeoRSS GML. Notice we use the
>> word "compliance". We spend weeks arguing whether we should
>> have "conformance" testing or "compliance" testing. Turns out that
>> there are very specific semantics associated with the use of those
>> words in the context of testing a standard or a profile of a standard
>> as to whether it meets the mandatory elements of the given standard.
>> I should also point out that there is a big difference between
>> compliance testing and interoperability testing. Just because an
>> implementation of a standard has tested to be compliant does not
>> guarantee interoperability - it only increases the probability of
>> interoperability..."
>> http://lists.oasis-open.org/archives/emergency-msg/200709/msg00041.html
>>
>> GML Application Schemas and Profiles
>> http://www.ogcnetwork.net/node/210
>>
>>
>> --------------------------------------------------------------------------
>> Random
>> --------------------------------------------------------------------------
>>
>>
>> Date: Wed, 31 Dec 2008 02:50:37 +1100
>> From: Rick Jelliffe <rjelliffe@allette.com.au>
>> To: Rex Brooks <rexb@starbourne.com>
>> Cc: xml-dev@lists.xml.org
>> Subject: Re: [xml-dev] Revisiting XML Profile
>> Rex Brooks wrote:
>>> Hi Folks,
>>>
>>> I'm returning to this list after a long absence because I'm
>>> working on a Profile of an existing Standard specification,
>>> and I'm looking for the best, most accurate and usable definition for
>>> a Profile that fits this purpose. I thought the Irish RIG profiles had
>>> a definition.
>>
>> I don't what has become of them: they are off-line now:
>> http://sdec.reach.ie/rigs
>>
>> I wrote about them here: http://oreilly.com/pub/wlg/6659
>> ["Great Irish Government subsets of XML Standards", March 2005]
>> http://lists.xml.org/archives/xml-dev/200812/msg00185.html
>>
>> =======
>>
>> Date: Thu, 16 Aug 2007 11:55:08 -0600
>> From: stephen.green@systml.co.uk
>> To: tag@lists.oasis-open.org
>> Subject: RE: [tag] Test Assertion Modeling - comments, etc
>>
>> Serm asked:
>>> Could this be handled with profiles?
>>
>> I'd guess not. A profile is a variation of the product being
>> standardized, not a variation of the way the standard is
>> defined for the same product. HTML for example wouldn't have
>> one profile for browser support and another for an HTML
>> editor and another for how XSLT might be used to convert it
>> to pdf. The whole point is to standardize the markup and maybe
>> include how a key app should handle it. I guess a standard is
>> best established by formally describing it then encouraging
>> and describing the primary application which would use it.
>> Other uses would be envisaged but not in detail since there
>> would need to be scope for innovative use or reuse built into
>> the way the standard is specified. I think 'levels' are just
>> a type of profile - one where there is some linear scale
>> linking the various profiles with scope for progressing from
>> one to another with more and more development/complexity.
>> I agree with David Marston's comment though
>> http://lists.oasis-open.org/archives/tag-comment/200708/msg00000.html
>> It describes the use of 'levels' and I agree that there is
>> scope to include this 'variability' in the profile - but not
>> to address the layers of which David Pawson speaks which are
>> the layers in the applications/business processes implementing
>> the standard/profile/level. Each level/profile has to address
>> each layer but the SBS tries to address all the layers in one go.
>> This means the conformance clause being vague enough to do so.
>> I don't think you can have one level (or profile) for each layer.
>> But you would probably need one version of a test requirement
>> and similarly one version of a test assertion (or set of them)
>> for a particular layer or range of layers in the applications
>> or for a particular type of application. Maybe there could one
>> conformance clause for each of these ranges of layers or types
>> of applications too.
>> -- Stephen Green
>> http://lists.oasis-open.org/archives/tag/200708/msg00024.html
>>
>> ----------
>>
>> [1] EM CAP Profiles SC (postings by Rex Brooks and others)
>>
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00007.html
>> *
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00002.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00008.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00009.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00011.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00012.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00013.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00014.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00015.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00016.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00017.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00018.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00019.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00020.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00021.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00022.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200812/msg00024.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00005.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00006.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00007.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00008.html
>> ->> ask-the-tab
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00009.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00010.html
>> http://lists.oasis-open.org/archives/emergency-cap-profiles/200901/msg00012.html
>>
>>
>> Cheers,
>>
>> - Robin
>>
>> Robin Cover
>> OASIS, Director of Information Services
>> Editor, Cover Pages and XML Daily Newslink
>> Email: robin@oasis-open.org
>> Staff bio: http://www.oasis-open.org/who/staff.php#cover
>> Cover Pages: http://xml.coverpages.org/
>> Newsletter: http://xml.coverpages.org/newsletterArchive.html
>> Tel: +1 972-296-1783
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
>
> ---------------------------------------------------------------------
> 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]