[IGS-DCWG-104] Re: Invitation to participate - IGS metadata, exchange via XML

[Fábián András]

Dear Colleagues,

On behalf of PosKEN, we would like to add some more general comments on this topic. I hope it will be valuable and won't be so late.

First off all the idea is welcomed to use such a kind of technology, which is offering an application friendly standard in the near future.
Our point of view the calibration method is the critical missing information in the sitelog. So it is very  necessary to create a brand new section for the calibration or create a new subsection in the antenna section. So we can select all kind of calibration methods and we should make an update with a new subsection at any calibration changes. In case we have a new individual calibration we have to give the opportunities to add the atx file availability. It might be an url or e-mail address. I can imagine a second option as well which is more flexible in automatic process. The sitelog can include all of the previous and the actually atx file. Additionally it is more generous to  create a kind of atx xml schema information in different namespace, which can be imported into our sitelog xml schema. Naturally the antenna calibration atx xml  is optionally not a mandatory information. it is a new standard so we have to make it as flexible as it can be. I think the standard should contain both of the options. Moreover an xml can  be more, than just a sitelog meta information. It would be possible to include all of the meta information for the station.
  
Connection between the XML sitelog and the general one:
* The SOPAC is welcomed  to be the base of   the xml construction. The first question is: Should we use the same information in the xml as the general sitelog contains? Naturally the conversion of  general sitelog to xml sitelog has to  be lossless. In my point of view the xml might contain more information, which can be usable addition information.
  
* It is well known, that we should create a new sitelog on every update (for example BALE_20080801.log,  BALE_20090427.log,  BALE_20090713.log) In spite of this the xml form can be  a kind of exportation from sitelog database and it should contain all of the updated information above. So the relationship between the xml sitelog and the human readable general sitelog might be one-to-many and we can integrate all the form information in one sitelog. So one xml file might contain all the change  managment information.
  
About update:
* In the near future we should handle the updates of sitelogs between the data centres. Under those circumstances it could be an autonomous method, if the sitelog contains only an update information, it will be updateable. On the other hand we should get ready for extreme situations when some kind of conflict occurred between sitelog information. In this case an automatic process could be critical and we should resolve it by hand.
  
Version Controlling:
* We are working on a new standard and we have to think about the applications which based on our new standard. Applications have to check if the actual xml meta information file is compatible with the actual version of application. We should prepare an xml version controlling system. For example in the SOPAC I found the version controlling information in the schema definition (version="0.0.1-beta"). The schema contains the information that informs applications that it has been changed. In that case an application could interrogate the version attribute, recognize that this is a new version of the schema, and take appropriate action. The main disadvantage of this version controlling is that the validator ignores the version attribute. Therefore, it is not an enforceable constraint. The second option would be  better than the earlier one. The XML Schema 1.1 has a new namespace, which is the version control namespace (vc:). vc:minVersion and vc:maxVersion might be placed as attributes on an element declaration to indicate which version of the schema specification the declaration was written to. So the xml element would inform the application if it is readable.

Version Controlling in the XML 1.1:
<element name=”…” vc:minVersion="1.1" vc:maxVersion="..">
…
</element>

General things about SOPAC:
* Generally the SOPAC schema is before my time. The schema is too simple, it doesn’t contain too much constraints and rules. In this case to avoid anomalies we definitely have to change all the schema definitions and set up some constraints. In this case we would enforce the user/application to use the same unified data stream. We just check all the rules in the schema definition on the validation process, which give us guarantee and ensure convention between the systems/applications. The xml schemas are tools, which offer more and more datatypes and rules. For this reason we should use all the possibility.
  
So first of all we have to set up some rules. The following definitions are only some examples, but we definitely have to change all the schema definition:
  
…
<xsd:simpleType name="LatCoordinate"> <!-- But it can be a decimal value also, with max and min value -->
         	<xsd:restriction base="xsd:string ">
         	<xsd:length value="10"/>
         	<xsd:pattern value="(\+|-)\d {2}[0-5]\d[0-5]\d.\d{2}"/>
         	</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ReportType ">
         	<xsd:restriction base="xsd:string ">
         	<enumeration value="UPDATE"/>
         	<enumeration value="NEW"/>
         	</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="LonCoordinate">
         	<xsd:restriction base="xsd:string ">
         	<xsd:length value="11"/>
         	<xsd:pattern value="(\+|-)(0|1)\d {2}[0-5]\d[0-5]\d.\d{2}"/>
         	</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DomesNumber">
         	<xsd:restriction base="xsd:string ">
         	      <xsd:length value="9"/>
<xsd:pattern value="\d{3}\d{2}(M|S) \d{3}"/>
         	</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name=" FormInformationID">
         	<xsd:restriction base="xsd:ID ">
<xsd:pattern value="1. (\d)*"/>
         	</xsd:restriction>
</xsd:simpleType>
…

  
Complex types are also incomplete. Therefore it isn’t contain all the rules, which is defined in the general sitelog information. For example I extend the FormInformation schema with some rules:
…
<xsd:complexType name="formInformationType">
<xsd:sequence>
<xsd:element name="id" type="FormInformationID" use=”required”/> <!—Use to distinguish and identifies the formInformation Instance, but usable all kind of identity at all major complex type -->
<xsd:element name="preparedBy" type="xsd:string" use=”required”/>
<xsd:element name="datePrepared" type="xsd:date" use=”required”/>
<xsd:element name="reportType" type=" ReportType " use=”required”/>
<xsd:element name="modifiedSection" type=" AddedSection"/>
</xsd:sequence>
</xsd:complexType>
…
  
Other additionally things:
*          XML 1.1 has been introduced at 2012, so we may use the new standard.
Link to the standard (about 400 pages ) :
-          http://www.w3.org/TR/xmlschema11-1/
-          http://www.w3.org/TR/xmlschema11-2/
  
Conclusion:
*The xml standard has waited for a long time, the idea is to use a ready to use solution is great, but we have many work on that and we should not hurry in this situation. Additionally we also have to change the standard of human readable format thinking of the antenna calibration method.


Best Regards:
Andras Fabian