emix — archive

[Anne Hendry <toby.considine@gmail.com>]

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