FWD: Re: [Tm4j-developers] Better handling of occurrence data

[Harald K. <har...@we...>]

Hi Kal,

I send this mail again because the smtp server of my free webmail service seems to be blocked by some spam blocker on sf.
Hope it works this time.


> Hi Harald,
>
> Thanks for the proposal. I have a few questions:
>
> 1) Do you think that we should continue to store the occurrence values
> as strings and only do the conversion on a get ? What about doing a
> conversion on a set ?

Yes, i think we should store the  occurrence values as strings because i think that tm4j should not check which format an occurence has (that is something for a schema or data type definition) but rather try to deliver a Format, the user request, return null if the data is not supported and an raise an Exception if the data does not comply to the Requested Format (this behavier is, in my opinion the way the Gang Of Four Pattern Adapter is meant to work - please correct me if i am wrong).

> 2) Is the Class parameter of the getAdapter method the class of the
> format you want (e.g. getAdapter(java.util.Date.class)) or is it the
> class of an adapter that does the conversion (e.g.
> getAdapter(org.tm4j.utils.DateAdapter)) - I guess from the way that you
> talk about using the occurrence type's base name for the formatting
> string, that you have an adapter class that you pass in as a parameter,
> right ?


It should be the the class of the format you want (yes, like getAdapter(java.util.Date.class)). We could think about using adapter classes but i just tried it with a getAdapter implementation witch is responsible for the generation of the adopted Format. Using the Basename of the type is just a way to make these time data interoperable (and the implementation is reduced to 3 or 4 lines of code).

> Finally there is discussion in the ISO working group about how to
> support data types in occurrences which will also have an influence on
> how TM4J behaves in the future - there are those who would like some
> base set of data types to be allowed for occurrences and those who would
> prefer just to allow any XML as occurrence data and then if you want
> data typing you use XML elements that have an associated schema that
> defines the data type. However, there is not a clear decision on that
> yet (AFAIK - I missed the last ISO WG meeting), so perhaps we can go
> with a solution like you propose for now and worry about what ISO come
> up with later.

I think that this is a good idea. As far as I know, ISO is not the fastest organisation concerning the decising about new standards.

Cheers,

Harald


________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193