Re: [emix] namespaces, versioning, and backward compatibility

[Anne Hendry <ahendry@pacbell.net>]

Hi Carl,

Thanks.  I would find the rationale for the policies would be the most 
helpful as a basis for discussion, rather than the policies themselves.  
If this is just for versioning hopefully there aren't many policies?

Best,
-A

Carl Reed wrote, On 4/4/2011 9:07 AM:
> Version numbers of documents and encodings and communication of 
> version(s) supported by an interface has been an ongoing dialogue in 
> the OGC ever since we started interface spec design. We have stated 
> policies. If these policies would help in the EMIX version discussion, 
> please let me know and I can provide them.
>
> Regards
>
> Carl
>
> ----- Original Message ----- From: "Anne Hendry" <ahendry@pacbell.net>
> To: <jeremy@lonmark.org>
> Cc: <emix@lists.oasis-open.org>
> Sent: Monday, April 04, 2011 9:28 AM
> Subject: Re: [emix] namespaces, versioning, and backward compatibility
>
>
>> Hi Jeremy,
>>
>> Yes, I think using the built-in attribute is very straightforward and 
>> easy to maintain.
>>
>> The aspect of using minor/major version numbers that has the most 
>> draw for me is that the format has recognizable meaning since it is 
>> used in most software versioning which should be familiar to people 
>> working with the standard schemas.  You can tell right away if you 
>> are looking at a major version (3.0) which may break compatibility, 
>> or a minor version that has a stable base (2.3.1).  How often have 
>> you made decisions on what to download just looking at those 
>> numbers?  I know I do that all the time. The recognition is 
>> instantaneous.  You can make decisions based on that immediate 
>> understanding.  It makes it easier, and more clear, for our eventual 
>> implementors and for end users as well.  No need to delve into the 
>> release first -- there is some immediate intelligence in the format 
>> and meaning of the numbers that is well understood in the software 
>> world.
>>
>> I also believe that it would make it easier to automate checking (say 
>> in a tool or an application) on whether you are looking at a 
>> backward-compatible version or not.
>>
>> -Anne
>>
>> Jeremy Roberts wrote, On 4/4/2011 7:06 AM:
>>> Hello, Anne:
>>>
>>> I think this is a great idea. I always hate invoking hindsight in a
>>> bandage manner; this is forward thinking. The "version" attribute isa
>>> part of "xs:schema" so I think we should use it (it's free and easy).
>>>
>>> Cheers,
>>> - Jeremy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Anne Hendry [mailto:ahendry@pacbell.net]
>>> Sent: Saturday, April 02, 2011 3:51 PM
>>> To: emix@lists.oasis-open.org
>>> Subject: [emix] namespaces, versioning, and backward compatibility
>>>
>>> I recall a discussion recently on versioning and backward
>>> compatibility. I'd like to propose we use a major/minor versioning
>>> scheme such that the major version is captured in the namespace but the
>>> minor version is captured in the schema element 'version' attribute.
>>> So, for instance, the current schema element declaration:
>>>
>>> <xs:schema targetNamespace="http://docs.oasis-open.org/ns/emix";
>>> elementFormDefault="qualified" attributeFormDefault="unqualified">
>>>
>>> would become
>>>
>>> <xs:schema targetNamespace="http://docs.oasis-open.org/ns/emix-1";
>>> elementFormDefault="qualified" attributeFormDefault="unqualified"
>>> version="1.0">
>>>
>>> This would allow for minor versions to be created/released without
>>> changing the namespace, maintaining backward compatibility across minor
>>> versions (as long as no other changes were made that broke
>>> compatibility).
>>>
>>> -Anne
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>