[moby] Re: [MOBY-dev] a question and a comment about the new Objectinheritance

[Pieter Neerincx]

On 27 May, 2005, at 21:43, ywong at infobiogen.fr wrote:

>> I like Yans idea, but what happens if the object doesn't
>> inherit from String, isn't an int or a float? What if the
>> object was a schematikonMotifID that inherits from
>> SchematikonSegmentID that inherits from Object. What would
>> the data:type be in this case?
>>
>> <schematikonMotifID articleName="" id="" namespace="">
>>         <String articleName="ID" id="" namespace=""/>
>> </schematikonMotifID>
>>
>> Ed
>>
>>
>>
>>> -----Original Message-----
>>> From: moby-dev-bounces at portal.open-bio.org [mailto:moby-
>>> dev-bounces at portal.open-bio.org] On Behalf Of
>>> ywong at infobiogen.fr
>>> Sent: Friday, May 27, 2005 10:55 AM
>>> To: markw at illuminae.com; Core developer announcements
>>> Subject: Re: [moby] Re: [MOBY-dev] a question and a
>>> comment about the new Objectinheritance
>>>
>>>> On Thu, 2005-05-26 at 16:50 +0100, Martin Senger wrote:
>>>>> Well, I myself is not the main player in this dicussion
>>> about inheriting
>>>>> from primitives but as far as I understand, this:
>>>>>
>>>>>> <String ns='' id=''>
>>>>>> 	<string>content here</string>
>>>>>> </String>
>>>>>>
>>>>>    is what everybody wanted in the meeting
>>>>
>>>> Ummmm... I think there was a lot of disagreement about
>>> what "everybody"
>>>> wanted... By the looks of it now, everybody wanted
>>> something different,
>>>> but were calling it the same thing :-)  Unfortunately,
>>> when I asked for
>>>> some example objects, nobody volunteered, so we couldn't
>>> sort it out at
>>>> the time.
>>>>
>>>> I remember vividly, however, that when I tried to write
>>> that (above XML)
>>>> on the screen, the room erupted in screams that I was
>>> making it all too
>>>> complicated, so I don't think that is what people
>> wanted.
>>> It may be
>>>> that we have all had time to digest the issue a bit more
>>> deeply now and
>>>> have come to the same conclusion?
>>>>
>>>> M
>>>>
>>>>
>>>> _______________________________________________
>>>> MOBY-dev mailing list
>>>> MOBY-dev at biomoby.org
>>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>>>
>>> Sorry I could reply earlier, all our network is in a
>>> quagmire...
>>>
>>> An alternative I would accept:
>>>
>>> <moby:Text-formatted data:type="string">
>>>    blablablablablablalbalbalblablalbalba
>>> </moby:Text-formatted>
>>>
>>>   An attribute is optional, we keep the actual version
>>> without killing
>>> everything (adding a subnode and all
>>> serializers/deserializers would
>>> have to be rewritten!)
>>>
>>>   People using Java will know what is the type of the data
>>> by reading this
>>> attribute. If it doesn't exist, they should assume that by
>>> default, it
>>> is a string.
>>>
>>>   Example of DNASequence:
>>>
>>>   <moby:DNASequence>
>>>     <moby:String articleName="SequenceString">
>>>
>>> ACTGTCAGCTAGCTAGCTCGATCGATCGATCGTACGTCGTACGTACGATCGT....
>>>     </moby:String>
>>>     <moby:Integer articleName="Length"
>>> data:type="int">152</moby:Integer>
>>>   </moby:DNASequence>
>>>
>>>   Then we should agree of what "primitives" we have:
>>>   -string
>>>   -float
>>>   -int
>>>
>>>   maybe are there others?
>>>
>>>   It is a quick and dirty solution however it is IMHO
>>> cleaner than what I
>>> saw in the last example. It has the advantage to keep the
>>> "old" object
>>> layout but add informations that will greatly help people
>>> who implements
>>> type sensible clients.
>>>
>>>   Greetings
>>>
>>> Yan
>>>
>>>
>>>
>>> _______________________________________________
>>> MOBY-dev mailing list
>>> MOBY-dev at biomoby.org
>>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at biomoby.org
>> http://www.biomoby.org/mailman/listinfo/moby-dev
>>
>
>
> Simple:
>   data:type only apply to the content of the tag if it exists so:
>
> <moby:Object moby:namespace="" moby:id="" data:type="int"/>
>
>   The line above means that the content of Object (here nothing) 
> should be
> an integer, but it is void so the line above describes an invalid
> integer...
>
> <moby:Object moby:namespace="" moby:id=""/>
>
> <schematikonMotifID articleName="" id="" namespace="">
>         <String articleName="ID" id="" namespace=""/>
> </schematikonMotifID>
>
> no data:type attribute and no content so we should deal this object as 
> we
> did before.
>
> <moby:Integer>152</moby:Integer>
>
> no data:type but a content, so the client must treat the content as a 
> string

Like Mark, I really like Yan's proposal for a data:type attribute, but 
I do think it should not be optional. If the people that use Java have 
to rely on this attribute to figure out what data type they are 
parsing, the example object above should be invalid. If 
<moby:Integer>152</moby:Integer> would be treated as string by a Java 
client and as integer by a client written in Perl, parsing BioMOBY data 
would no longer be language independent and that would be a very bad 
thing.

If we would introduce a data:type attribute, having the element name 
indicating the same thing is a bit redundant. Furthermore I think it is 
makes more sense to identify an element based on it's name as compared 
to having multiple elements with the same name and then using the 
articleName attribute to figure out what is what. If we have a 
data:type attribute the element names no longer have to be String, 
Integer, etc. and we actually completely forget the articleName 
attribute. This would break a lot of the stuff that is already running 
though...

Cheers,

Pieter

>
> <moby:Integer data:type="int">152</moby:Integer>
>
> the data:type indicates that the content is an integer.
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
>