Data Model utype

[François Bonnarel]

Hi all,
      On this discussion, I think it's wrong to attach namespaces to xml.
xml namespaces are precisly defined but there are NAMESPACES in other
contexts. So as far as utypes are concerned stc: is not an "xml 
namespace", I
agree, but is a namespace anyway.
Cheers
  see below more details




Le 16/04/2010 14:46, Markus Demleitner a écrit :
> Hi all,
>
> On Fri, Apr 16, 2010 at 12:38:39PM +0200, Mireille Louys wrote:
>    
>> You're right , better to have short Utypes so I would suggest :
>>
>> DataModel.Name instead of DataModelReference.Name for instance
>>      
> Great -- I'll have that in the STC note coming up, then.
>
>    
>> I agree we do not parse Utypes , so 'stc:' in 'stc:AstroCoords' is not a
>> name space , but it gives the context  of the utype  .
>> We could have it as
>>
>> DataModel.Prefix
>>
>> if you prefer.
>>      
> Hm -- I don't quite understand this.  What would the value of that
> utype be?  Transmitting
>
> stc:Datamodel.Prefix ->  stc
>
> doesn't help, does it?
>
>    
I don't think it can be stc:Datamodel.Prefix, because that would mean 
that Datamodel is an attribute
of the stc model. I think "ivoa" or "ivoadm" (for generix 
ivoiadefinition" ) is more appropriate.
so something like
     utype = ivoadm:DataModel.Prefix value="stc:/char:/obs:/spec:/..."


>> My take is that each datamodel should provide  a recommended versionned
>> Utype list , published in the IVOA
>> so this prefix could work as a pointer to the utypelist document , in the
>> same way as the name space 'stc' points to the STC xml schema in an
>> instance XML document.
>> in other words ,
>>
>> DataModel.Prefix can be mapped to DataModel.Uri DataModel.Uri could point
>> to the published Utypelist
>>      
> Again -- I'm not quite sure I understand.  Why do you want to define
> DataModel.Prefix?  By the requirement that utypes should not require
> parsing, the prefix for stc utypes must *always* be stc and nothing
> else.  The utypes
>
> stc:AstroCoordSystem.href
>
> and
>
> dm0:AstroCoordSystem.href
>
> must have *no* relationship whatsoever unless we give up the "don't
> have to parse" requirement.  To illustrate what I'm worried about,
> I'd tend to believe I could have something like
>
> dm0:Prefix ->  stc  (?)
> dm0:URI ->  http://www.ivoa.net/xml/STC/stc-v1.30.xsd
> dm0:AstroCoordSystem.href ->  TT-ICRS
>
>    
    No you will have
  ivoadm:Prefix  ---> stc
  ivoadm:URI ---> http://www.ivoa.net/xml/STC/stc-v1.30.xsd
stc:AstroCoordSystem.href -> TT-ICRS




> and have that equivalent to
>
> stc:Prefix ->  stc  (?)
> stc:URI ->  http://www.ivoa.net/xml/STC/stc-v1.30.xsd
> stc:AstroCoordSystem.href ->  TT-ICRS
>
> -- and that, I think, would be a grave mistake since users couldn't just
> use string matching to figure out the values for roles in data
> models.
>
>
>    
>> which allow then for an application to check the utypes properly
>>      
> Let me try and describe what I think is "good enough" for that
> purpose again:
>
> (1) Each utype set (e.g., a group containing STC, but also maybe a
> text file containing utype-value mappings) SHOULD define the data
> model it is written against.  It does so in a utype-value pair
> with utype<data model id>:DataModel.URI.
>
> (2) If given, DataModel.URI SHOULD be a URL that, when asked for
> HTML, should return human-readable documentation on the DM
>
> (3) If not DataModel.URI is not given, the receiving application is
> free to assume any data model.
>
> This allows applications that care *very* strongly to check what DM
> *version* they are supposed to understand.  The (at least) 80% of the
> programs that just need some way to figure out "this is the error to
> that coordinate, and it's in GALACTIC" can ignore this, and they are
> even free to dump STC info into VOTables or somewhere else without
> having to worry about URIs.
>
> Admittedly, this means that we're not free to change the meaning of
> stc:AstroCoords.Position2D.Value2.C1, and we're not allowed to "fix"
> the utype list and suddenly say "it's stc:coo.pos.c1 now".  But I
> strongly believe that kind of stability is a definite *must* if we
> ever want astronomers to take advantage of this kind of shallow
> semantics.
>
> If and when we get a fixed STC machinery, there's always stc2: (that
> could even live happily togehter with stc:).
>
> Cheers,
>
>             Markus
>
>
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20100416/15f4ff5c/attachment-0001.html>