[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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]