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


Help: OASIS Mailing Lists Help | MarkMail Help

tab-askthetab message

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

Subject: Specification Profiles, Application Profiles, Layers...

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.


* 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
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 ===

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

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

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 [...]

Singapore Framework for Dublin Core Application Profiles

DCMI Abstract Model

Description Set Profile Specification

Dublin Core Collections Application Profile

Eprints Application Profile

Open Geospatial Consortium (OGC) Profilea and Application Profiles

OGC Specification Profiles

The OGC Standards and Specifications
  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

   "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


OGC Releases GML Simple Features Profile Specification for Review

"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

GML Application Schemas and Profiles


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: 

I wrote about them here: http://oreilly.com/pub/wlg/6659
["Great Irish Government subsets of XML Standards", March 2005]


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
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


[1] EM CAP Profiles SC (postings by Rex Brooks and others)

  ->> ask-the-tab


  - 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

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