updates to dm mapping document

[Gerard Lemson]

Dear all
I promised in Madrid to compose an email with alternatives for the use of 'utype' in the current utypes mapping document (*). I think the following options have all been discussed and should be on the table, in increasing amount of complexity and/or required changes:

1. do not change anything.
I.e. leave mapping document as it is. Keep using the utype attribute for pointing into VO-DML models.
This option MUST be on the table for discussion. It reduces amount of work required and, importantly, does not require any changes to VOTable standard.
The latter was something the utypes tiger team tried hard to avoid during its work.

2. add 1 new attribute to some VOTable elements, which will be used instead of the 'utype' attribute wherever that is currently used in the mapping document. This attribute is only necessary for GROUP, PARAMref, PARAM and FIELDref elements.
This attribute was referred to as 'dmtype' in Madrid discussions. Might better be called something like 'vodml-role' if the ONLY change to the mapping document will be to use this attribute wherever it currently uses 'utype'. After all, the current mapping document suggests that utype-s should always identify VO-DML Roles, not Types. Types are used for casting purposes only in the existing utypes document, and are identified as 'value'
in a special <PARAM> (or possibly as a <FIELDref>!) inside a GROUP. 

3. add 2 attributes to VOTable, for sake of argument named 'dmrole' and 'dmtype' (or vodml-role, vodml-type) . The former would replace the current use of utype (as in proposal 2). For the 'dmtype' attribute there would be two usages:
i) it would replace the <PARAM> used for type casting purposes. Disadvantage is that a 'dmtype'  attribute would only represent a single type (assuming we don't want parsing of these attributes to discover multiple, ;-separated values). But in the current proposal we give publishers the option to explicitly add multiple types from a type inheritance hierarchy in the annotation, especially when types are inherited across model boundaries (ask for details if this is unclear). 
ii) it is used for "root" GROUPs, i.e. GROUP-s representing instances that do not play a role in another GROUP in the VOTable. The dmrole attribute would not be used. The current design introduces a somewhat ad-hoc "vo-dml:Instance.root" role that must be used for GROUP-s that are not contained in a parent GROUP. This would not be necessary.

4. add  a complexType, say 'VODMLAnnotation' to VOTable, with components <vodml-type> (maxOccurs=unbounded) and <vodml-role>; their usage should be obvious. This type is used for a new <vodml> (minOccurs=0) element on GROUP, FIELDref, PARAM and PARAMref. 


My comments on these options:
Option 1 has the lowest impact, namely none at all. It requires no changes, either in VOTable or in utypes mapping document. 

Option 2 has lowest impact of the possible alternatives I suppose, only adds one attribute to a select number of VOTable elements. In MY opinion it is a weird compromise though. Why is it ok to have dmrole do exactly what the utype would do in the proposal, but is it not acceptable to use the utype attribute itself for that purpose? The utypes proposal mandates a prefix that MUST be declared explicitly as an identifier of a VO-DML model. I.e.
these utypes and their interpretation are clearly identifiable. Why is that not sufficient? But if this is what it takes to move forward it is acceptable.

Option 3 removes a slight ugliness in the existing design once we accept option 2. Sometimes a casting is required, or at least desirable. In the current proposal we use a special <PARAM> for that purpose. This means that the type and role annotation are now at different levels, where one might expect them to be close. This slightly complicates the parsing. However this proposal has the disadvantage that if we want to allow multiple type annotations, the dmtype would have to be composite. I don't think this is a useful compromise.

Option 4 is in my opinion the most elegant solution. Imho it is how utype should have been defined from the beginning, not as an attribute, but as an element. Many of the design issues would have been trivial to solve. We might even have used a special VODMLType or so that would extend a more generic UTYPE type, and an xsi:type would have been sufficient to indicate the special kind of annotation used. Hence from design considerations this option has my preference. But introducing a new element, rather than one or two attributes apparently has the biggest impact on existing VOTable parsers and so may be objected to.


Note, if we accept one of options 2-4, I think we MUST change the definition of the utype attribute in existing specs. It should not be thought of as a "pointer into a data model". For example we might change it to something like the following, which I think represents the current usage of those who have problems with the proposal as it is:
"The 'utype' attribute can be used as custom annotation to identify an element in  a particular context, for example a custom application or an IVOA standard access protocol. There are no constraints on its format, simple string comparison to some list defined by the context should be sufficient. The precise context SHOULD be declared elsewhere in the VOTable in a manner specified by the application. Outside of this context, there is no requirement for clients to be able to interpret the meaning. In particular, for generically identifying elements in terms of a standard data model the 'vodml-role' attribute [or whatever we come up with] MUST be used as specified in [ref to mapping document]."

Cheers
Gerard


(*) Latest version of document can be found at volute: http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-WD-v1.0.pdf. 
See also http://wiki.ivoa.net/twiki/bin/view/IVOA/UTYPES for related links, especially to VO-DML doc.