OASIS Energy Market Information Exchange (eMIX) TC

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    

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

Detailed thoughts below. This follows the W3 conventions quite well (except where they seem to think that there is one version per year). Summary: Approach 2, adding /06 for the current schemas and namespace. URI for the schemas themselves is determined by the TC Admin. Plain namespace (without the date) seems to always dereference to the latest namespace document. This is useful, but not to program with. Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 6/12/11 11:00 AM, Toby Considine wrote: 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: NO.   Has the problem that it assumes one version per year. 003601cc2911$84def990$8e9cecb0$@gmail.com type= cite > 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 YES with the changes shown - adding /06 to each. There is an issue about the subnamespaces (thinking in URI-speak) as to whether they would have their own Namespace document or a copy of that for the top; it's also been suggested that in parallel, the first namespace should end with emix/ -- since the overall namespace is emix, I don't think that's needed. Also, I believe (trivial issue) that the prefix does not include the : but instead is separated from the reference by : - in any event it should be consistent so it's not emix: and siscale ... 003601cc2911$84def990$8e9cecb0$@gmail.com type= cite > Table 1 €‘1: XML Namespaces in this standard Prefix Namespace emix: http://docs.oasis-open.org/ns/emix/2011/06/ siscale http://docs.oasis-open.org/ns/emix/2011/06/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 NO. Need year/data in the namespace, unless it's perfect and we'll never ever have another version :-) 003601cc2911$84def990$8e9cecb0$@gmail.com type= cite > 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.     I don't like this at all. Then if we do 1.1 in September, then does 2011 get updated? This seems to lead to confusion.   Seems very bad to have that be the case.. In any event, the OASIS rules and the TC Admin determine the artifact location. For example, EMIX PR02 (CSPRD02) artifacts (XSD) are at http://docs.oasis-open.org/emix/emix/v1.0/csprd02/xsd/ and referenced by the namespace document at http://docs.oasis-open.org/ns/emix (NOTE no final / ) It does appear that there is no structure below that namespace that's easily discoverable; the base namespace is there for emix, ws-calendar, etc, and gives the most recent versions. So the namespace ending with ...emix would give you the latest; referencing the actual date gives you that version. As I said, I'm not sure whether the emix namespace is useful except to find the particular namespace defined and the schemas. 003601cc2911$84def990$8e9cecb0$@gmail.com type= cite >   €œ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    

I tend to prefer YYYY/MM in the namespace to denote version.   From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com] Sent: Sunday, June 12, 2011 1:18 PM To: emix@lists.oasis-open.org Subject: Re: [emix] Hot Topic: Namespaces and Versioning   Detailed thoughts below. This follows the W3 conventions quite well (except where they seem to think that there is one version per year). Summary: Approach 2, adding /06 for the current schemas and namespace. URI for the schemas themselves is determined by the TC Admin. Plain namespace (without the date) seems to always dereference to the latest namespace document. This is useful, but not to program with. Thanks! bill -- William Cox Email: wtcox@CoxSoftwareArchitects.com Web: http://www.CoxSoftwareArchitects.com +1 862 485 3696 mobile +1 908 277 3460 fax On 6/12/11 11:00 AM, Toby Considine wrote: We have yet to deal completely with Schema and namespace versioning.   One approach would look like the following: NO.  Has the problem that it assumes one version per year. 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   An alternate approach would look like YES with the changes shown - adding /06 to each. There is an issue about the subnamespaces (thinking in URI-speak) as to whether they would have their own Namespace document or a copy of that for the top; it's also been suggested that in parallel, the first namespace should end with "emix/" -- since the overall namespace is emix, I don't think that's needed. Also, I believe (trivial issue) that the prefix does not include the ":" but instead is separated from the reference by ":" - in any event it should be consistent so it's not emix: and siscale ... Table 1 ??1: XML Namespaces in this standard Prefix Namespace emix: http://docs.oasis-open.org/ns/emix/2011/06/ siscale http://docs.oasis-open.org/ns/emix/2011/06/siscale power: http://docs.oasis-open.org/ns/emix/2011/power resource: http://docs.oasis-open.org/ns/emix/2011/power/resource   Still another, which we seem to have adopted implicitly is NO. Need year/data in the namespace, unless it's perfect and we'll never ever have another version :-) 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.     I don't like this at all. Then if we do 1.1 in September, then does 2011 get updated? This seems to lead to confusion.  Seems very bad to have that be the case.. In any event, the OASIS rules and the TC Admin determine the artifact location. For example, EMIX PR02 (CSPRD02) artifacts (XSD) are at http://docs.oasis-open.org/emix/emix/v1.0/csprd02/xsd/ and referenced by the namespace document at http://docs.oasis-open.org/ns/emix (NOTE no final "/") It does appear that there is no structure below that namespace that's easily discoverable; the "base" namespace is there for emix, ws-calendar, etc, and gives the most recent versions. So the namespace ending with ...emix would give you the latest; referencing the actual date gives you that version. As I said, I'm not sure whether the "emix" namespace is useful except to find the particular namespace defined and the schemas.   ??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