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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emix message

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


Subject: Re: [emix] Hot Topic: Namespaces and Versioning


Toby,

You neglected to represent the discussion on the TC list in April which lays out (to my mind) a good argument and support for using a common software versioning scheme (major.minor version numbers, eg. 1.0, 1.1, 2.0, ...) with many benefits over a date-centric scheme, as discussed in the following threads:

http://lists.oasis-open.org/archives/emix/201104/msg00154.html

Referring to the thread response from Carl, see Chapter 13 (XML Implementation and Versioning) of the document he sent (and also attached here).  As originally suggested, the OGC guidelines also recommend use of the xsd 'version' attribute for minor revisions removing the need to update the namespace for minor revisions.  The original suggestions was to use a major.minor scheme.  The OGC uses a three-number scheme using the second minor number for bug fix releases.  That is a choice for the TC to make.

The two-number major.minor scheme has been used successfully for years by other OASIS TCs.

This would make, for example, the 'emix' namespace something like:

http://docs.oasis-open.org/ns/emix/1.0
or
http://docs.oasis-open.org/ns/emix/1  (then string "1.0" captured in the xsd 'version' attribute)

or
http://docs.oasis-open.org/ns/emix-1.0
or
http://docs.oasis-open.org/ns/emix-1 (then string "1.0" captured in the xsd 'version' attribute)

Read email thread for remainder of thoughts on why this direction should be considered by the TC.


-Anne








Toby Considine wrote, On 6/12/2011 8:00 AM:
003601cc2911$84def990$8e9cecb0$@gmail.com" type="cite">

We have yet to deal completely with Schema and namespace versioning.

 

(1)    One approach would look like the following:

Table 1‑1: XML Namespaces in this standard

Prefix

Namespace

emix:

http://docs.oasis-open.org/ns/emix/2011

siscale

http://docs.oasis-open.org/ns/emix/siscale/2011

power:

http://docs.oasis-open.org/ns/emix/power/2011

resource:

http://docs.oasis-open.org/ns/emix/power/resource/2011

 

(2)     An alternate approach would look like

Table 1‑1: XML Namespaces in this standard

Prefix

Namespace

emix:

http://docs.oasis-open.org/ns/emix/2011/

siscale

http://docs.oasis-open.org/ns/emix/2011/siscale

power:

http://docs.oasis-open.org/ns/emix/2011/power

resource:

http://docs.oasis-open.org/ns/emix/2011/power/resource

 

(3)     Still another, which we seem to have adopted implicitly is

Table 1‑1: XML Namespaces in this standard

Prefix

Namespace

emix:

http://docs.oasis-open.org/ns/emix/

siscale

http://docs.oasis-open.org/ns/emix/siscale

power:

http://docs.oasis-open.org/ns/emix/power

resource:

http://docs.oasis-open.org/ns/emix/power/resource

 

There are then the various approaches which summarize as “putting v1.0 in place of the 2011 in alternates (1) and (2)

 

 

This is confusing similar to but not identical to the similar issue of persistence of artifacts. In general, I recommend that we remain consistent with W3C Guidelines which are oft-quoted as follows:

 

<xs:annotation>

  <xs:documentation>In keeping with the XML Schema WG's standard versioning

   policy, this schema document will persist at

   http://www.w3.org/2005/08/xml.xsd.

   At the date of issue it can also be found at

   http://www.w3.org/2001/xml.xsd.

   The schema document at that URI may however change in the future,

   in order to remain compatible with the latest version of XML Schema

   itself, or with the XML namespace itself.  In other words, if the XML

   Schema or XML namespaces change, the version of this document at

   http://www.w3.org/2001/xml.xsd will change

   accordingly; the version at

   http://www.w3.org/2005/08/xml.xsd will not change.

  </xs:documentation>

</xs:annotation>

 

This would result in a statement as follows:

 

In keeping with the XML Schema WG's standard versioning policy, the schemas defined in this specification will persist in http://docs.oasis-open.org/ns/emix/2011/06/. At the date of issue, each can also be found at http://docs.oasis-open.org/ns/emix/2011/. The schema documents at that URI may however change in the future, in order to remain compatible with the latest version of EMIX Specification. In other words, if the schemas namespaces change, the version of these document at http://docs.oasis-open.org/ns/emix/2011/ will change accordingly; the versions at http://docs.oasis-open.org/ns/emix/2011/06/ will not change.

 

 

 


“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw.


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

OGC_policies.doc



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