Re: [emergency] RE: Profiles - what do we mean by the term?

[creed@opengeospatial.org]

Art -

Extensions properly done and vetted by consensus do not break
interoperability. Extensions will not "damage" a standard. I am not sure
why you have this belief. For example, the OASIS ebRIM standard is
designed to allow extensions and in fact encourages the use of extensions.
If one does a bit of research on the use of extensions in the standards
community, we quickly find that RUBY, JAVA, PCIM, LDAP and dozens of other
standards support the ability to define extensions.

And I am only using China as an example.

Anyway, let's get the email out and capture requirements first and then
figure the best way forward.

Regards

Carl




> Yes, what's been suggested of late is an extension rather than a profile.
> I'm in favor of profiles, but extensions are notorious for breaking
> compatibility.
>
> Look, if someone could being us a commitment from China that if we'd
> complicate the spec in this way they'd adopt CAP, I might actually be
> persuaded it was a worthwhile trade-off.
>
> But that's not the situation.  What we're
> talking about is doing definite damage to a successful standard, in terms
> of increased complexity and reduced interoperability, in hopes of gaining
> unspecified future benefits that are at best speculative and in any event
> largely symbolic.
>
> Technical consideratons aside, that strikes me as a pretty naïve way of
> doing business.
>
> - Art
>
> -----Original Message-----
> From: "Carl Reed OGC Account" <creed@opengeospatial.org>
> To:  <emergency@lists.oasis-open.org>
>
> Sent: 11/27/2007 6:18:17 PM
> Subject: [emergency] RE: Profiles - what do we mean by the term?
>
> During the call today, the term "profile" was used numerous times. I am
> not sure we all have a common understanding by what we mean by a
> "profile". In ISO and the OGC, we use the following definition:
>
> A profile is a strict subset of a Standard applicable to multiple
> Application Schemas. This is from ISO 19109 and is typically used in the
> context of XML schema.
>
> If we use this definition, then a profile of CAP, or EDXL for that matter,
> would be a subset - not an extension, optional or otherwise. I am not sure
> that this is what we want. As soon as a group adds elements or changes the
> meaning of an existing element to meet local conditions, this is NOT a
> profile!
>
> I think that several of us have been talking about is the concept of an
> extension. In the OGC, we have been having a strong dialogue about a
> general pattern for the development of all OGC standards. We call this
> model core-extension. Sometime in 2008, the membership will approve this
> pattern as policy to be used in the development of all OGC standards.
>
> Essentially what this means is that for most any standard (interface,
> payload, etc) it is possible to define a core set of
> elements/functionality that has an associated set of conformance clauses.
> The standard also provides guidance as to how to define extensions.
> Extensions allow for adding new elements or functionality - they do not
> break the core. This means that any organization implementing the core can
> achieve a desired level of interoperability and feel very confident that
> the core standard will not change much over a fairly long period of time.
> At the same time, extensions can be developed the enable the use of the
> core in other information domains, communities, programs, regions, and so
> forth - again without any modifications to the core. Further, extensions
> need not go through a standards organization for approval - unless the
> group that developed the extension wants to go to the effort.
>
> Now, for a standard that is already in use and implemented, there may be
> some modification required to the existing standard (core) in order to
> enable the ability to define extensions. We already have some of this
> capability to define extensions in EDXL-RM and perhaps in DE but I am not
> familiar enough with DE.
>
> So, in a way, I see the evolution of CAP using the core-extension design
> pattern as potentially a very positive move. CAP as we know it may stay
> pretty much as is: relatively simple, fairly easy to implement, and
> meeting specific requirements in a well defined community.  However, we
> may also be able to define a consistent approach to enabling extensions
> that allow for such capabilities as the specification of alternate
> coordinate reference systems, multiple coordinate reference systems,
> additional geometries, multiple geometries, time, and so forth. Such an
> approach protects current investment, future proofs the core standard,
> allows more communities to engage and use the standard. The list of
> benefits is quite long and very well documented.
>
> I am not trying to fan any fires here. And I definitely do not develop
> standards for standards sake! I spent 25 years as a software engineer,
> lead design engineer, and then chief architect for a number commercial GIS
> products before joining the OGC. I am very pragmatic about how we develop
> and use standards.
>
> Time to go watch House.
>
> Cheers
>
> Carl Reed, PhD
> CTO and Executive Director Specification Program
> OGC
>
> The OGC: Helping the World to Communicate Geographically
>
> ---------------------
>
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, any use, copying,
> disclosure, dissemination or distribution is strictly prohibited. If you
> are not the intended recipient, please notify the sender  immediately by
> return email and delete this communication and destroy all copies.
>
> "The important thing is not to stop questioning." -- Albert Einstein
> "Security is mostly a superstition. It does not exist in nature. Life is
> either a daring adventure or nothing." -- Helen Keller
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>