Using @version to indicate the schema version

[Paul Harrison]

Hi,


I have had an initial edit of the Schema versioning note 1.1 into volute based on my previous email. (BTW - I am moving towards just sticking with “version" as the instance document attribute name - with a provision that if your schema already had a “version” in the top level elements that is used for something else - e.g. VODML then you use “stdVersion”)

There is another question on this topic that I am not sure if we should worry about or not, is again related to schema namespaces. In the past - e.g UWS the version attribute has been locally defined in the relevant top level element, which means that it can be referred to in the instance documents without a namespace (attributes are normally in the “unnamed” namespace)

It might be nicer in schema definition terms (i.e. only having to define the attribute once) - e.g. for VOSITables to do

<xsd:schema targetNamespace="http://www.ivoa.net/xml/VOSITables/v1.0"
            xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0"
            xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.1"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified"
            version="1.1-REC-err1">

  <xsd:annotation>
     <xsd:documentation>
       A schema for formatting table metadata as returned by a 
       tables resource, defined by the IVOA Support Interfaces 
       specification (VOSI). 
       See http://www.ivoa.net/Documents/latest/VOSI.html.  
     </xsd:documentation>
  </xsd:annotation>

  <xsd:import namespace="http://www.ivoa.net/xml/VODataService/v1.1"
              schemaLocation="./VODataService-v1.1.xsd" />

<xsd:attribute name="version" type="xsd:string" default="1.0">
  <xsd:annotation>
     <xsd:documentation>
       This is used to signal which major.minor version of the VOSI standard the response document follows.
       It is named version rather than the now recommended stdVersion for historical reasons.
     </xsd:documentation>
  </xsd:annotation>  
</xsd:attribute>

  <!--
    -  the root element for a VOSI tableset metadata
    -->
  <xsd:element name="tableset" >
     <xsd:annotation>
       <xsd:documentation>
         A description of the table metadata supported by the 
         service associated with a VOSI-enabled resource.
       </xsd:documentation>
     </xsd:annotation>
    <xsd:complexType>
       <xsd:complexContent>
          <xsd:extension base="vs:TableSet">
             <xsd:attribute ref="vosi:version" use="optional"></xsd:attribute>
          </xsd:extension>
       </xsd:complexContent>
    </xsd:complexType>
  </xsd:element>

  <!--
    -  single table root element for a VOSI table metadata
    -->
  <xsd:element name="table">
     <xsd:annotation>
       <xsd:documentation>
         A description of a single table supported by the
         service associated with a VOSI-enabled resource.
       </xsd:documentation>
     </xsd:annotation>
    <xsd:complexType>
       <xsd:complexContent>
          <xsd:extension base="vs:Table">
             <xsd:attribute ref="vosi:version" use="optional"></xsd:attribute>
          </xsd:extension>
       </xsd:complexContent>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>


but then it would mean that the instance document would need to use the following namespace definitions 

<vosi:tableset
  xmlns:vosi="http://www.ivoa.net/xml/VOSITables/v1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:vs="http://www.ivoa.net/xml/VODataService/v1.1"  
  vosi:version="1.1">

In the end I guess that it does not matter which style is used as long as the xml is valid - I just worry that people often just "cut and paste” examples from the IVOA standards when deciding how to form their XML and consequently get it wrong…

Paul.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1905 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20180830/7cd3f259/attachment.p7s>