Anne, Jeremy, and others --
This has gotten off track of the original theme, I think, which was
namespace maintenance AKA versioning.
I'm repeating and extending an earlier message to put it in this
thread; it's really very effective to keep this discussion in
comments on the namespace Jira item, EMIX-317 and one I've created
for possible schema version inclusion discussion -- having separate
discussions apart from the issues makes it harder to work
efficiently in my experience, so please put your comments as this
thread matures into the Jira items.
WS-Calendar uses for namespace definition (as do many OASIS
specifications) the year and month of publication. Using the date
to disambiguate namespaces is a common approach. See (e.g.) Service
Component Architecture, WS-Calendar, and more.
A time sequence of major/minor versions is identified by the date.
The most frequently changing versions we've had are working drafts,
where we sometimes have several (including "wip") a week. But the
namespace changes at Committee Specification Drafts and Committee
Specification.
The benefit of the scheme in
http://www.oasis-open.org/committees/download.php/41708/EMIX_Namespace_Declarations_and_Maintenance_Policy_20110403.rtf
is that it identifies the production date; the disadvantage (minor
IMO) is that it doesn't readily support minor revisions that are
more frequent than monthly.
I've also found that the management of major/minor for specs like
this is often more costly than the benefit obtained.
Finally, we use a schemaVersion attribute in Energy Interop to
identify the schema version in major classes. The same approach
might be used in EMIX, and given the relationships of the specs it
should be the same mechanism and same naming in Calendar, EMIX, and
EI.
My next note will explore the pluses and minuses of creating and
using a schema versioning mechanism in addition to the required
namespace maintenance plan.
Thanks!
bill
On 4/4/11 12:07 PM, Carl Reed wrote:
E74DE475BA1D4FD2996EC0BB69EB4375@CarlandSusieOf"
type="cite">Version numbers of documents and encodings and
communication of version(s) supported by an interface has been an
ongoing dialogue in the OGC ever since we started interface spec
design. We have stated policies. If these policies would help in
the EMIX version discussion, please let me know and I can provide
them.
Regards
Carl
----- Original Message ----- From: "Anne Hendry"
<ahendry@pacbell.net>
To: <jeremy@lonmark.org>
Cc: <emix@lists.oasis-open.org>
Sent: Monday, April 04, 2011 9:28 AM
Subject: Re: [emix] namespaces, versioning, and backward
compatibility
Hi Jeremy,
Yes, I think using the built-in attribute is very
straightforward and easy to maintain.
The aspect of using minor/major version numbers that has the
most draw for me is that the format has recognizable meaning
since it is used in most software versioning which should be
familiar to people working with the standard schemas. You can
tell right away if you are looking at a major version (3.0)
which may break compatibility, or a minor version that has a
stable base (2.3.1). How often have you made decisions on what
to download just looking at those numbers? I know I do that all
the time. The recognition is instantaneous. You can make
decisions based on that immediate understanding. It makes it
easier, and more clear, for our eventual implementors and for
end users as well. No need to delve into the release first --
there is some immediate intelligence in the format and meaning
of the numbers that is well understood in the software world.
I also believe that it would make it easier to automate checking
(say in a tool or an application) on whether you are looking at
a backward-compatible version or not.
-Anne
Jeremy Roberts wrote, On 4/4/2011 7:06 AM:
Hello, Anne:
I think this is a great idea. I always hate invoking hindsight
in a
bandage manner; this is forward thinking. The "version"
attribute isa
part of "xs:schema" so I think we should use it (it's free and
easy).
Cheers,
- Jeremy
-----Original Message-----
From: Anne Hendry [mailto:ahendry@pacbell.net]
Sent: Saturday, April 02, 2011 3:51 PM
To: emix@lists.oasis-open.org
Subject: [emix] namespaces, versioning, and backward
compatibility
I recall a discussion recently on versioning and backward
compatibility. I'd like to propose we use a major/minor
versioning
scheme such that the major version is captured in the
namespace but the
minor version is captured in the schema element 'version'
attribute.
So, for instance, the current schema element declaration:
<xs:schema
targetNamespace="http://docs.oasis-open.org/ns/emix"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
would become
<xs:schema
targetNamespace="http://docs.oasis-open.org/ns/emix-1"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="1.0">
This would allow for minor versions to be created/released
without
changing the namespace, maintaining backward compatibility
across minor
versions (as long as no other changes were made that broke
compatibility).
-Anne
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
|