Followup to Re: utype questions
thomas at astro.umd.edu
Thu Jul 2 11:00:50 PDT 2009
Well, I suppose I wasn't precise or clear enough in my last email to
provide substantive criticism of the Utype proposal to which others
might respond. In fact, re-reading it, it does look like I
am only trolling for a fight, and this is not my intention (nor
is it to insult the proposers, so please accept my apology
if that is how my last email was taken!).
I am, in fact, very much in support of the idea behind the Utype
proposal that components of one data model may be shared/re-used
within another. What I have issue with is the present description
and the limitations which occur because of the choices the authors
have made. As I will attempt to illustrate below, I believe some
of these limitations are fatal to the purpose of the proposal and
create (presently) and unworkable spec except for the very simplest
cases of use.
So. Allow me to re-try my criticism from another angle, which will
hopefully be clearer to the rest of the community.
To start with, from reading the documentation (reference ,;
with additional modifying possible proposals:  ) I understand the
following main points about Utypes:
A. Represent data model elements (, pg 1)
B. May be serialized in a VOTable as param elements or fields of
the table (, pg 5).
C. Elements may be complex or simple, single values ( pg 10)
D. Use the grouping mechanism in VOTable to be used for multiple instances
of the same model within a single file ( pg 10,  pg 16).
E. Utype syntax ( pg 8) is meant to represent components of a model.
It is composed of elements model-name, package-name, class-name and
includes a final position for properties which may be one of
attribute-name, collection or reference (using XML ID/IDREF mechanism,
 pg 10). Some sort of chaining mechanism exists for naming Utypes
which occur within other models ( bottom of pg 10 and illustrated
in  on pg. 7)
Now on to questions problems which I see in the present document:
1. Where is the description of the ID/IDREF mechanism for the Utype
syntax? Much depends on this working properly, including how easily
the parser will be able to associate various parent model element
instance to the correct child model instances, the ability
to correctly order collected child model elements (important in
some cases, will you infer this from the order of appearance of
model elements in the file? If so, its not mentioned), and just
how this might be made to work within the context of a FITS file
(or HTML table for that matter, as mentioned in ) is very unclear.
2. Why use of the grouping mechanism in VOTable to handle multiple instances
of a model? This means that the Utype spec is not a complete standalone
specification. You are relying on an outside structure (grouping) to
provide meaning to the reconstructed model (ie. which child nodes belong
to which parents). If I wanted to use Utypes for FITS tables or HTML,
then what do I replace the grouping mechanism with?
3. Why is the chaining mechanism important? If the grouping and
ID/IDREF referencing is working, you don't need it (child will already
know the parent).
And now some criticism based on the above.
1. Without working examples for FITS/HTML which use referencing and
grouping, I can only conclude that this proposal really only amounts
to a modification of the VOTable specification. Utypes spec relies on
outside structures to function, namely the grouping which is an element
of VOTable, and ID/IDREF is an XML mechanism which doesn't exist in FITS.
Please explain how Utypes are to be used with nesting/referencing in FITS and
provide examples of the ID/IDREF mechanism at work.
2. Why isn't it reasonable to use an existing XML/XML-schema mechanism of
import/redefine to allow 'foreign' model elements within the VOTable? This
is well-tested, XML parsers grok it already, and its standard practice.
I assume that it must be related to some requirements which are not
present in  (I see that in  the Utypes are supposed to allow the
'application to treat the Utypes as opaque strings'). All sorts of bad
things flow from the present specification, here's a short list:
* You *must* modify the VOTable parser (to understand Utype attribute,
the grouping, and the special ID/IDREF mechanism of Utypes). No
allowance for passing over.
* Not possible to create a stand-alone library for grokking Utypes,
instead it will have to be tightly integrated with the parser (VOTable,
FITs, and whatever is reading your HTML tables, should that be
attempted as well).
Please consider a different nesting/referencing mechanism from the present ones.
3. I wonder if repeated objects must be sent, why use VOTable to serialize
them? Why not develop a light-weight collection model in XML, and allow
compression of the contents? The amount of application/semantics work
looks to be about the same to me.
Furthermore, unless serendipity reigns, you are going to require the re-
factoring of various data models so that they conform to Utype standard. Are
you suggesting this is mandatory for all VO accepted models or will their
be a contributory list of kosher models which work with Utype? Again, this
adds work to implementation of Utypes successfully.
Even if not mandatory, some models will have to be re-factored (along with
any existing software based on them), so some work will exist for this.
Along with the work on the VOTable parser, it seems like significant effort
will be needed to implement this proposal.
Please point out the savings of doing it in this manner over a simpler
approach of importing/redefing elements in XML.
Well, that's enough for now (I have tried to stick purely with  and
to main problem points, I have some support for and criticism of 
and , but I don't want to run on).
Hopefully I have been precise and clear. I have tried to cite the material
as well as read it closely. It is possible that I missed something which
has led to my misunderstanding and I am happy to be corrected on this.
Again, this is written in the spirit of substantive criticism, not a flame
 Utype: a data model field name convention, v0.3, IVOA Note draft,
May 24, 2009
 Utype proposals, Norman Grey, 2009?,
 Utypes and URIs, IVOA Note,v1.0, 2007, Norman Grey
 Simple Spectral Access Protocol, v104,
More information about the dm