Re: [emergency-cap-profiles] Specification Profiles, ApplicationProfiles, Layers...

[Rex Brooks <rexb@starbourne.com>]

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

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