XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
| ||||||||
Added: | ||||||||
> > |
| |||||||
-- MarkusDemleitner - 2016-07-18
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Minor editorial: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Approved.
-- PatrickDowler - 2018-02-14
Applications Working Group ( _Pierre Fernique, Tom Donaldson ) | ||||||||
Changed: | ||||||||
< < | I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context. I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. | |||||||
> > | I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context. I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. | |||||||
Added: | ||||||||
> > |
| |||||||
-- PierreFernique - 2016-04-25
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )We consider that this managing of minor ad major versions is well written and allow a major improvement for standards development and management. We accept it but we agree with the concerns on introduction of section 2 as stated by others. We also would like to read in the intro that this note is part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note | ||||||||
Changed: | ||||||||
< < | Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural changes" section 3 "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace the actual file than the first from of the URL above points to must be updated when a new minor version is published."must be updated when a new minor version is published." ????? We don't catch this ... maybe this means : ---> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? | |||||||
> > | Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural changes" | |||||||
Added: | ||||||||
> > |
| |||||||
-- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )I believe that the approach described to supporting minor changes to a major version in a client compatible way is complicated, but probably the best that can be done in such circumstances. We at the CADC are using this approach in services that involve UWS 1.0 and 1.1, and it is working well. I approve of this document and the process it describes. There is certainly a lot of effort required in order to maintain backward compatibility, both by the writers of the specifications and the implementors. I wonder if the IVOA should consider moving to a model where backward compatibility (between both major and minor versions) isn't a requirement. Service providers could explicitly offer different versions in parallel for some period of time, giving time for client to upgrade. Maybe something to discuss in the future. -- BrianMajor - 2017-12-18Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )I approve the document and appreciate it offers a way to trace minor corrections to the XML schema in the long term , when a specification gets real feedback and uptake and requires light fixes on the .xsd document. It will remain up to the main authors of the corresponding specification to decide whether the changes are just minor , and issue XML schema update only , or whether a specification update is needed. -- MireilleLouys - 2018-01-26Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler ) | ||||||||
Added: | ||||||||
> > | Minor editorial:
| |||||||
Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )We consider that this managing of minor ad major versions is well written and allow a major improvement for standards development and management. We accept it but we agree with the concerns on introduction of section 2 as stated by others. We also would like to read in the intro that this note is part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural changes" section 3 "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace the actual file than the first from of the URL above points to must be updated when a new minor version is published."must be updated when a new minor version is published." ????? We don't catch this ... maybe this means : ---> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? -- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )I believe that the approach described to supporting minor changes to a major version in a client compatible way is complicated, but probably the best that can be done in such circumstances. We at the CADC are using this approach in services that involve UWS 1.0 and 1.1, and it is working well. I approve of this document and the process it describes. There is certainly a lot of effort required in order to maintain backward compatibility, both by the writers of the specifications and the implementors. I wonder if the IVOA should consider moving to a model where backward compatibility (between both major and minor versions) isn't a requirement. Service providers could explicitly offer different versions in parallel for some period of time, giving time for client to upgrade. Maybe something to discuss in the future. -- BrianMajor - 2017-12-18Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi ) | ||||||||
Changed: | ||||||||
< < | I approve the document and appreciate it offers a way to trace minor corrections to the XML schema in the long term , when a specification gets real feedback and uptake and requires light fixes on the .xsd document. | |||||||
> > | I approve the document and appreciate it offers a way to trace minor corrections to the XML schema in the long term , when a specification gets real feedback and uptake and requires light fixes on the .xsd document. | |||||||
Changed: | ||||||||
< < | It will remain up to the main authors of the corresponding specification to decide whether the changes are just minor , and issue XML schema update only , or whether a specification update is needed. | |||||||
> > | It will remain up to the main authors of the corresponding specification to decide whether the changes are just minor , and issue XML schema update only , or whether a specification update is needed. | |||||||
-- MireilleLouys - 2018-01-26
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )We consider that this managing of minor ad major versions is well written and allow a major improvement for standards development and management. We accept it but we agree with the concerns on introduction of section 2 as stated by others. We also would like to read in the intro that this note is part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural changes" section 3 "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace the actual file than the first from of the URL above points to must be updated when a new minor version is published."must be updated when a new minor version is published." ????? We don't catch this ... maybe this means : ---> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? -- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni ) | ||||||||
Changed: | ||||||||
< < | I believe that the approach described to supporting minor changes to a major version in a client compatible way is complicated, but probably the best that can be done in such circumstances. We at the CADC are using this approach in services that involve UWS 1.0 and 1.1, and it is working well. I approve of this document and the process it describes. | |||||||
> > | I believe that the approach described to supporting minor changes to a major version in a client compatible way is complicated, but probably the best that can be done in such circumstances. We at the CADC are using this approach in services that involve UWS 1.0 and 1.1, and it is working well. I approve of this document and the process it describes. | |||||||
Changed: | ||||||||
< < | There is certainly a lot of effort required in order to maintain backward compatibility, both by the writers of the specifications and the implementors. I wonder if the IVOA should consider moving to a model where backward compatibility (between both major and minor versions) isn't a requirement. Service providers could explicitly offer different versions in parallel for some period of time, giving time for client to upgrade. Maybe something to discuss in the future. | |||||||
> > | There is certainly a lot of effort required in order to maintain backward compatibility, both by the writers of the specifications and the implementors. I wonder if the IVOA should consider moving to a model where backward compatibility (between both major and minor versions) isn't a requirement. Service providers could explicitly offer different versions in parallel for some period of time, giving time for client to upgrade. Maybe something to discuss in the future. | |||||||
-- BrianMajor - 2017-12-18
Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi ) | ||||||||
Added: | ||||||||
> > | I approve the document and appreciate it offers a way to trace minor corrections to the XML schema in the long term , when a specification gets real feedback and uptake and requires light fixes on the .xsd document. It will remain up to the main authors of the corresponding specification to decide whether the changes are just minor , and issue XML schema update only , or whether a specification update is needed. -- MireilleLouys - 2018-01-26 | |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro ) | ||||||||
Changed: | ||||||||
< < | We consider that this managing of minor ad major versions is well written | |||||||
> > | We consider that this managing of minor ad major versions is well written and allow a major improvement for standards development and management. We accept it but we agree with the concerns on introduction of section 2 as stated by others. We also would like to read in the intro that this note is part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note | |||||||
Deleted: | ||||||||
< < | and allow a major improvement for standards development and management. We accept it but we agree with the concerns on introduction of section 2 as stated by others. We also would like to read in the intro that this note is part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note | |||||||
Added: | ||||||||
> > | Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural changes" section 3 "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace the actual file than the first from of the URL above points to must be updated when a new minor version is published."must be updated when a new minor version is published." ????? We don't catch this ... maybe this means : ---> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? | |||||||
Changed: | ||||||||
< < | Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural | |||||||
> > | -- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11 | |||||||
Deleted: | ||||||||
< < | changes"
section 3
"As this note now recommends that there are potentially many minor versions
of a schema all in the same namespace the actual file than the first from of
the URL above points to must be updated when a new minor version is
published."must be updated when a new minor version is published." ????? We
don't catch this ... maybe this means :
> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? | |||||||
Deleted: | ||||||||
< < | -- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11 | |||||||
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni ) | ||||||||
Added: | ||||||||
> > | I believe that the approach described to supporting minor changes to a major version in a client compatible way is complicated, but probably the best that can be done in such circumstances. We at the CADC are using this approach in services that involve UWS 1.0 and 1.1, and it is working well. I approve of this document and the process it describes. There is certainly a lot of effort required in order to maintain backward compatibility, both by the writers of the specifications and the implementors. I wonder if the IVOA should consider moving to a model where backward compatibility (between both major and minor versions) isn't a requirement. Service providers could explicitly offer different versions in parallel for some period of time, giving time for client to upgrade. Maybe something to discuss in the future. -- BrianMajor - 2017-12-18 | |||||||
Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro ) | ||||||||
Added: | ||||||||
> > |
We consider that this managing of minor ad major versions is well written
and allow a major improvement for standards development and management. We
accept it but we agree with the concerns on introduction of section 2 as
stated by others. We also would like to read in the intro that this note is
part of standard and processes policy. The new "IVOA Document standards" doculent should refer also to the present endorsed note
Typos : page 3 2.1 "Specific structual changes" ---> "Specific structural
changes"
section 3
"As this note now recommends that there are potentially many minor versions
of a schema all in the same namespace the actual file than the first from of
the URL above points to must be updated when a new minor version is
published."must be updated when a new minor version is published." ????? We
don't catch this ... maybe this means :
> "As this note now recommends that there are potentially many minor versions of a schema all in the same namespace, the actual file that the first form of the URL above points to must be updated when a new minor version is published." ??? -- FrancoisBonnarel - 2017-01-11 -- MarcoMolinaro - 2017-01-11 | |||||||
Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and Approvals | ||||||||
Changed: | ||||||||
< < | Document Link: XML Schema Versioning Policies | |||||||
> > | Document Link: XML Schema Versioning Policies | |||||||
Comments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and Approvals | ||||||||
Changed: | ||||||||
< < | Document Link: XML Schema Versioning Policies | |||||||
> > | Document Link: XML Schema Versioning Policies | |||||||
Comments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Reply from Paul Harrison | ||||||||
Changed: | ||||||||
< < | on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that | |||||||
> > | on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. | |||||||
Deleted: | ||||||||
< < | did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. | |||||||
end reply
Other extremely minor items:
+ section 2.2: has a double 'the'.. "it becomes imperative that the the minor"
+ since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD.
-- MarkCresitelloDittmar - 2016-05-02
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! What I mean is <doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc> | ||||||||
Changed: | ||||||||
< < | are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). | |||||||
> > | are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). | |||||||
end reply
Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2.
(2) In
Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? | ||||||||
Added: | ||||||||
> > | Reply from Paul Harrison on the subject of must - what this means in practice is that the 1.1 standards document has to say the version attribute must be added, but in practice for the 1.1 schema the attribute can only be marked as 'optional' to be in compliance with a 1.0 instance that did not have the attribute. Of course a new 1.0 level schema created after this note should add the version attribute as a mandatory attribute from the beginning. end reply | |||||||
Other extremely minor items:
+ section 2.2: has a double 'the'.. "it becomes imperative that the the minor"
+ since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD.
-- MarkCresitelloDittmar - 2016-05-02
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent Reply from Paul Harrison This has confused two people so it is probably does need a better exposition! | ||||||||
Changed: | ||||||||
< < | What I mean is | |||||||
> > | What I mean is | |||||||
<doc xmlns="http://example.com/1.0"> <anelement/> </doc> | ||||||||
Changed: | ||||||||
< < | and | |||||||
> > | ||||||||
Added: | ||||||||
> > | and | |||||||
<doc xmlns="http://example.com/1.1"> <anelement/> </doc> | ||||||||
Changed: | ||||||||
< < | are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). | |||||||
> > | are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). | |||||||
Added: | ||||||||
> > | ||||||||
end reply
Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2.
(2) In
Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from the interested public | ||||||||
Changed: | ||||||||
< < | One problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example | |||||||
> > | One problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example | |||||||
Added: | ||||||||
> > | This is problematic if we intend to evolve the schemas to new versions, because the namespace will insinuate something that is patently untrue. For instance (and this is already happening) the namespace of version 1.2 of the SIA registry extension will be http://www.ivoa.net/xml/SIA/v1.1. | |||||||
Changed: | ||||||||
< < | This is problematic if we intend to evolve the schemas to new versions, because the namespace will insinuate something that is patently untrue. For instance (and this is already happening) the namespace of version 1.2 of the SIA registry extension will be http://www.ivoa.net/xml/SIA/v1.1. | |||||||
> > | In the future, this kind of thing is fairly easy to avoid: Only put the major version into the namespace; I suppose we should use things like http://www.ivoa.net/xml/SIA1, http://www.ivoa.net/xml/SIA2, and so on (where this particular example stinks a bit because the extension schema is maintained independently of the standard). | |||||||
Changed: | ||||||||
< < | In the future, this kind of thing is fairly easy to avoid: Only put the major version into the namespace; I suppose we should use things like | |||||||
> > | For the transition, this isn't suitable. We have the "broken" namespaces. | |||||||
Deleted: | ||||||||
< < | http://www.ivoa.net/xml/SIA1, http://www.ivoa.net/xml/SIA2, and so on (where this particular example stinks a bit because the extension schema is maintained independently of the standard). | |||||||
Deleted: | ||||||||
< < | For the transition, this isn't suitable. We have the "broken" namespaces. | |||||||
I see a couple of escape routes. | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
Opinions? -- MarkusDemleitner - 2016-07-18 | ||||||||
Deleted: | ||||||||
< < | ||||||||
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/> | ||||||||
Changed: | ||||||||
< < | indeed are equivalent. | |||||||
> > | indeed are equivalent | |||||||
Added: | ||||||||
> > |
Reply from Paul Harrison
This has confused two people so it is probably does need a better exposition!
What I mean is
<doc xmlns="http://example.com/1.0"> <anelement/> </doc>and <doc xmlns="http://example.com/1.1"> <anelement/> </doc>are formally completely different XML - but as we know that the schema are related via an updated IVOA standard, in fact the "anelement" element really means the same in both documents. It is this observation that drives the idea that, as the bulk of the elements in a point update will be the same, the namespace should not be changed (even though this goes against "conventional wisdom"). end reply | |||||||
Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2.
(2) In
Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning Policies | ||||||||
Added: | ||||||||
> > | Comments from the interested publicOne problem I see with the proposal is transitioning. Unfortunately, most of our namespaces actually have a minor version in them. Consider, for example
| |||||||
Comments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel ) | ||||||||
Changed: | ||||||||
< < | The approach seems very sensible and appropriate for the IVOA. | |||||||
> > | The approach seems very sensible and appropriate for the IVOA. | |||||||
Opinions on other comments: | ||||||||
Changed: | ||||||||
< < | + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. | |||||||
> > | + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. | |||||||
Changed: | ||||||||
< < | + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. | |||||||
> > | + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. | |||||||
Changed: | ||||||||
< < | + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? | |||||||
> > | + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? | |||||||
Other extremely minor items: | ||||||||
Changed: | ||||||||
< < | + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" | |||||||
> > | + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" | |||||||
Changed: | ||||||||
< < | + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. | |||||||
> > | + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. | |||||||
-- MarkCresitelloDittmar - 2016-05-02
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent. Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson )I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context.I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel ) | ||||||||
Added: | ||||||||
> > | The approach seems very sensible and appropriate for the IVOA. Opinions on other comments: + about TCG role (2.1.1). I agree that it should be careful about the role of the TCG in determining the version. For backward compatibility items, this should be straight forward and responsibility is on the author side. For errata issues, it seems more likely that the effects will be cross group.. a minor change from the DM perspective, may have larger repercussions on the Registry.. so more TCG involvment may be needed. + section 2 intro: I found the wording of the fist sentence confusing.. (not equivalent if only difference is the namespace declaration).. seemed like a typo. I needed the rest to clarify the intent. I think there is purpose to the paragraph, but I think the phrasing could be improved. Also, the case described, would only be true if there were no new 'optional' elements added in the instance. + section 2.2.1: "root elements must have a version attribute". I'm not too familiar with the details there.. but. Adding a 'must', would invalidate current responses which don't include it, so this may have to be a 'strongly encouraged' type of thing. I'm not sure I understand Marcus' comments about the root element, but specifying where to find this information seems like a good thing. If not on the root element.. where? Other extremely minor items: + section 2.2: has a double 'the'.. "it becomes imperative that the the minor" + since the 'official' schema will be associated only with REC standards, I'd prefer the example 'version' texts be for RECs, not PR or WD. -- MarkCresitelloDittmar - 2016-05-02 | |||||||
Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent. Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning PoliciesComments from TCG membersWG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )Applications Working Group ( _Pierre Fernique, Tom Donaldson ) | ||||||||
Added: | ||||||||
> > | I totally approve the purpose of this note. It is a pragmatic approach for improving the interoperability without breaking the necessary protocol validation level. It is perfectly adapted to the IVOA context. I have one point to precise before approving it formally : Is it really the responsability of the TCG to decide if a standard evolution requires just a minor update mechanism, or more ? (section 2.1.1). I suppose that the authors of a standard evolution are certainly more able to know if the backward compatibility is, or is not guarantee. The TCG should just check the proposal. And a suggestion: the syntax of the minor and major number version should be probably explained somewhere at the begining of the document. -- PierreFernique - 2016-04-25 | |||||||
Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )Registry Working Group ( _Markus Demleitner, Theresa Dower )(1) I'm not sure I like the language ofWe can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes.(introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since <doc xmlns="http://example.com/ns"/>and <ns:doc xmlns:ns="http://example.com/ns"/>indeed are equivalent. Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2. (2) In Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo )
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning Policies | ||||||||
Changed: | ||||||||
< < | ---++ Comments from TCG members | |||||||
> > | Comments from TCG members | |||||||
Changed: | ||||||||
< < | WG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory. | |||||||
> > | WG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory. | |||||||
Changed: | ||||||||
< < | ---+++ TCG Chair & Vice Chair ( Matthew Graham, Pat Dowler ) | |||||||
> > | TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler ) | |||||||
Changed: | ||||||||
< < | ---+++ Applications Working Group ( Pierre Fernique, Tom Donaldson ) | |||||||
> > | Applications Working Group ( _Pierre Fernique, Tom Donaldson ) | |||||||
Changed: | ||||||||
< < | ---+++ Data Access Layer Working Group ( François Bonnarel, Marco Molinaro ) | |||||||
> > | Data Access Layer Working Group ( François Bonnarel, Marco Molinaro ) | |||||||
Changed: | ||||||||
< < | ---+++ Data Model Working Group ( Mark Cresitello-Dittmar, Laurent Michel ) | |||||||
> > | Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel ) | |||||||
Changed: | ||||||||
< < | ---+++ Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni ) | |||||||
> > | Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni ) | |||||||
Changed: | ||||||||
< < | ---+++ Registry Working Group ( Markus Demleitner, Theresa Dower ) | |||||||
> > | Registry Working Group ( _Markus Demleitner, Theresa Dower ) | |||||||
Changed: | ||||||||
< < | ---+++ Semantics Working Group ( Mireille Louys, Alberto Accomazzi ) | |||||||
> > | (1) I'm not sure I like the language of | |||||||
Changed: | ||||||||
< < | ---+++ Education Interest Group ( Massimo Ramella, Sudhanshu Barway ) | |||||||
> > | We can use the observation that simply removing the namespace definition from both instances would make the instances both textually the same and equivalent in the strict XML sense to inform the class of changes can be to the schema definition without necessarily needing to change the namespace, and how a client should treat such changes. | |||||||
Changed: | ||||||||
< < | ---+++ Time Domain Interest Group ( John Swinbank, Mike Fitzpatrick ) | |||||||
> > | (introduction to section 2). I have an uncanny feeling that I don't understand what this is intended to mean. Also, it may be confusing in this context, even more so since | |||||||
Changed: | ||||||||
< < | ---+++ Data Curation & Preservation Interest Group ( Françoise Genova ) | |||||||
> > | ||||||||
Added: | ||||||||
> > | | |||||||
Changed: | ||||||||
< < | ---+++ Operations Interest Group ( Tom McGlynn, Mark Taylor ) | |||||||
> > | and | |||||||
Changed: | ||||||||
< < | ---+++ Knowledge Discovery in Databases Interest Group ( George Djorgovski ) | |||||||
> > | ||||||||
Added: | ||||||||
> > | | |||||||
Changed: | ||||||||
< < | ---+++ Theory Interest Group ( Franck Le Petit, Carlos Rodrigo ) ---+++ Standards and Processes Committee ( Françoise Genova) | |||||||
> > | indeed are equivalent. | |||||||
Added: | ||||||||
> > |
Plus, I think we should not even suggest removing the namespace declarations might be a good idea under any circumstances, as doing this is certain to cause major interoperability problems as soon as the resulting tree is serialised again. I'd vote to remove the entire introductory paragraph to section 2.
(2) In
Hence, in service responses, root elements must have a \xmlel{version} attribute exactly giving the value of the corresponding XSD file's \xmlel{version} attribute.I'm doubtful of the must. Ok, it is limited to "service responses", but that's a term not clearly defined. In VOResource, for instance, I don't think vr:Resource/@version is terribly useful; worse, the root element of actual responses of OAI-PMH-services is a container element we don't even control. And VOResource doesn't have global elements in the first place. So, I'm much rather have language like: For such applications, protocols should place \xmlel{version} attributes, typically on the root element(s) of the schema. Their values exactly correspond to the value of the \xmlel{version} attribute on the \xmlel{xs:schema} (i.e., root) element of the XML schema file against which a given piece of software was implemented.And then we could strike the sentence "When the discovery of ... may be left out" further down. (3) I think the global exposition would profit if we first discuss xs.schema/@version (current sect 2.2.2) and only then talk about @version in instance documents -- since the schema file is the source of the version string, that seems a bit more logical. (4) While I personally am a big fan of the plural "schemata", I feel obliged to mention that if we wrote "schema files" instead, we'd probably be subscribing to less controversial terminology. None of the above points is really serious, though, so regardless of how they are eventually decided, I approve of this document. Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Operations Interest Group ( _Tom McGlynn, Mark Taylor )Knowledge Discovery in Databases Interest Group ( George Djorgovski ) Theory Interest Group ( _Franck Le Petit, Carlos Rodrigo ) | |||||||
<--
|
XML Schema Versioning Policies: Endorsed Note - Request for TCG Comments and ApprovalsDocument Link: XML Schema Versioning Policies---++ Comments from TCG members
WG chairs or vice chairs must read the Note, provide comments if any and formally indicate if they approve or do not approve of the Note. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.
---+++ TCG Chair & Vice Chair ( Matthew Graham, Pat Dowler )
---+++ Applications Working Group ( Pierre Fernique, Tom Donaldson )
---+++ Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )
---+++ Data Model Working Group ( Mark Cresitello-Dittmar, Laurent Michel )
---+++ Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )
---+++ Registry Working Group ( Markus Demleitner, Theresa Dower )
---+++ Semantics Working Group ( Mireille Louys, Alberto Accomazzi )
---+++ Education Interest Group ( Massimo Ramella, Sudhanshu Barway )
---+++ Time Domain Interest Group ( John Swinbank, Mike Fitzpatrick )
---+++ Data Curation & Preservation Interest Group ( Françoise Genova )
---+++ Operations Interest Group ( Tom McGlynn, Mark Taylor )
---+++ Knowledge Discovery in Databases Interest Group ( George Djorgovski )
---+++ Theory Interest Group ( Franck Le Petit, Carlos Rodrigo ) ---+++ Standards and Processes Committee ( Françoise Genova)
<--
|