UCD elements

Martin Hill mchill at dial.pipex.com
Thu Jul 1 11:31:46 PDT 2004


We will need (at latest when we introduce UCD2 over UCD1+) simultaneous UCDs of 
different versions in single metadata documents (so both older and newer tools 
can use them).

If I understand this right, namespaces are a bit heavy and make it awkward to 
use several UCD tags in the one document (we would have to define a namespace 
for each UCD version - I don't think you need an xsd to do this - and specify 
the namespace for each tag).  And I believe you can enumerate attribute values, 
so it would be straightforwared to have <UCD> with an unambiguous set of 
attribute "version" values.

However by using namespaces we can type the element properly, and so handle more 
complex forms of UCDs as Roy has said, allowing us to break them down as 
appropriate for each UCD version. And we can define element names (eg as <UCD> 
and <UcdPlus>) with types defined by namespaces in the schema, which doesn't 
look too nasty to use in the instance documents.

So the former is simple to implement and will always work as long as UCDs can be 
represented as strings (is that not one of their requirements?), the latter 
'correct' but quite horrible for developers?

Ray Plante wrote:

> On Thu, 1 Jul 2004, Matthew Graham wrote:
> 
>>I am inclined to agree with Guy and Ed that using appropriate namespaces
>>is the way forward on this one.
> 
> 
> This assumes that there is an xsd being defined for version 1 and 1+.  To 
> date, we have neither, nor am I aware that there are plans to create them.  
> Without them, it's not appropriate to use the XML Schema namespace 
> mechanism. 
> 
> I think a simple, optional version attribute will be sufficient.  The 
> value can be "1", "1+", etc.  Or if you need to be absolutely unambiguous 
> (e.g. to prevent "1.0" from screwing things up) you use a URI as the 
> value (e.g. "http://www.ivoa.net/ucd/v1+").
> 
> cheers,
> Ray
> 
> 
> 

-- 
Martin Hill
www.mchill.net
+44 7901 55 24 66




More information about the registry mailing list