xtype: similarity to VODataService's externalType
Rob Seaman
seaman at noao.edu
Thu May 28 12:37:00 PDT 2009
Does this discussion seem as inscrutable to people onsite? :-) Here
is the only email I've found where dateTime is mentioned in a VO
context:
>> From: Arnold Rots <arots at head.cfa.harvard.edu>
>> Date: April 20, 2006 10:53:03 AM GMT-07:00
>> To: Rob Seaman <seaman at noao.edu>
>> Cc: VOTable mailing list <votable at ivoa.net>, Mark Taylor <m.b.taylor at bristol.ac.uk
>> >
>> Subject: Re: String representations of numeric values
>>
>> ISO-8601 is not a problem; it can be handled through xs:dateTime.
>>
>> - Arnold
Perhaps a pointer to some more extensive (VO) discussion about
xs:dateTime? I presume we're meant to start somewhere like:
http://www.w3.org/TR/xmlschema-2/#dateTime
Meanwhile Doug's discussion seems just a teensie weensie itsy bitsy
obscure...certainly we should expect none of our users to ever
comprehend the difference between XTYPE and UTYPE.
Combining the two, is it possible that xtype is a solution to a
general class of problem that has already been solved in the w3
context by particular structures like dateTime?
Rob
-----
On May 28, 2009, at 12:21 PM, Arnold Rots wrote:
> I probably should have reminded people, for the record, of something I
> mentioned a long time ago: that the whole business of ISO-8601 time
> stamps could be avoided if VOTable were to recognize the datatype
> xs:datetime.
>
> - Arnold
>
> Douglas Tody wrote:
>> Hi -
>>
>> As I mentioned in the VOTable session, we need to be very careful
>> to distinguish XTYPE from UTYPE. So XTYPE is used to define a
>> "custom type". But an "abstract type" sounds very similar, but can
>> be an object or data model, which is where UTYPE is already used.
>>
>> The distinction should be that anything which has an XTYPE is an
>> atomic type which could be used anywhere (not defined as an element
>> of
>> some data model), and which can be mapped to a primary type such as
>> any VOTable datatype. Basically it is used to extend the "machine"
>> level typing system to say things such as a primitive type of string
>> contains a timestamp or STC-S region.
>>
>> We can probably ensure against semantic confusion by insisting that
>> an
>> XTYPE be storable in a single item of primitive type, and manipulated
>> atomically as a primitive type would be, at the layer where the type
>> is defined. It would be possible to abuse this simple concept by
>> serializing an object as a string or blob, but if it can nonetheless
>> be manipulated as an atomic object at the level where the datatype
>> is defined (as in storing an object in a field of a table) this might
>> still be ok.
>>
>> Hence a FIELD or PARAM (and maybe INFO for consistency although I
>> would be happy with only having string there) can have an XTYPE,
>> but GROUP should not, nor any higher level non-atomic construct
>> which has some internal structure. If it can't have a "datatype",
>> it can't have an XTYTPE. This is for VOTable, but if VODataService
>> deals with this as well it should be consistent.
>>
>> - Doug
>>
>>
>> On Thu, 28 May 2009, Ray Plante wrote:
>>
>>> Hi VOTablers,
>>>
>>> As discussed in the last VOTable session in Strasbourg, we are
>>> considering
>>> adding a new FIELD attribute called xtype (or exttype or
>>> externalType).
>>> As I mentioned, this is very similar to an attribute availble in
>>> VODataService for describing a table column.
>>>
>>> For reference, here's how the VODataService Document
>>> (http://www.ivoa.net/Documents/latest/VODataService.html) describes
>>> them...
>>>
>>> More descriptive information about the type can be provided via
>>> the
>>> extendedType and extendedSchema, which provide an alternate data
>>> type
>>> name. It's expected that this name will only be understood by a
>>> special
>>> subset of applications. The name given in the element content,
>>> then,
>>> represents a more commonly understood "fall-back" type.
>>>
>>> extendedType Value type: string: xs:string.
>>> Semantic Meaning: the data value represented by
>>> this
>>> type can be interpreted as of a
>>> custom type identified by the
>>> value
>>> of this attribute.
>>> Occurrences: optional
>>> Comments: The name implies a particular
>>> expected format for the data
>>> value that can be parsed into a
>>> value in memory.
>>>
>>> If an application does not
>>> recognize
>>> this extendedType, it should
>>> attempt
>>> to handle value assuming the
>>> type
>>> given by the element's value.
>>> "string" (or its equivalent)
>>> is a
>>> recommended default type.
>>>
>>> This element may make use of
>>> the
>>> extendedSchema attribute and/
>>> or any
>>> arbitrary (qualified)
>>> attribute to
>>> refine the identification of
>>> the
>>> type.
>>>
>>> extendedSchema Value type: URI: xs:anyURI.
>>> Semantic Meaning: An identifier for the schema
>>> that
>>> the value given by the extended
>>> attribute is drawn from.
>>> Occurrences: optional
>>> Comments: This attribute is normally
>>> ignored if
>>> the extended element is not
>>> present.
>>>
>>> hope this is helpful for reference.
>>>
>>> cheers,
>>> Ray
>>>
>>
> --------------------------------------------------------------------------
> Arnold H. Rots Chandra X-ray Science
> Center
> Smithsonian Astrophysical Observatory tel: +1 617
> 496 7701
> 60 Garden Street, MS 67 fax: +1 617
> 495 7356
> Cambridge, MA 02138 arots at head.cfa.harvard.edu
> USA http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/votable/attachments/20090528/b0861113/attachment-0003.html>
More information about the votable
mailing list