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

[Kal A. <ka...@te...>]

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 ?

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 ?

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.

Cheers,

Kal

On Thu, 2004-08-19 at 18:17, Harald Kuhn wrote:
> Hi All,
> 
> I thought about how to implement a better handling of data inside occurrences. This approach should also bring a better support for later adding support for xml inside occurrence data.
> 
> I suggest to add an Interface named OccurrenceData (or OccurrenceContent, i am not quite sure which is the better name)  which encasulates the Data of an Occurrence. The Occurrence Interface would have to be extended with the methods getOccurrenceData(...) and setOccurrenceData(..) (or getOccurrenceContent and setOccurrenceContent). The Methods getData() and setData() should be kept for compatibility reasons. The OccurrenceData (or OccurrenceContent) would have the following methods:
> 
> String getData / void setData(String)  have the same behavier like getData/setData of Occurrence
> StringReader getStringReader() returns a StringReader containing the data
> Object getAdapter(Class clazz)
> 
> Following the Adapter Pattern would make the support of other Data Formats easier to implement. It would also prevent the interface from getting to complex blown up.
> 
> The basic implementation should support the creation of the following Instances throug its getAdapter Method:
> 
> java.util.Date (for Temporal Data)
> org.xml.sax.InputSource (for XML Data)
> javax.xml.transform.Source (returning a javax.xml.transform.stream.StreamSource)  (for XML Data)
> 
> further DataFormats that might be interesting are:
> some class that understands Wiki Formatting instructions
> some class that understands spatial data 
> (Christoph, is there a STandart API or something like that ?)
> 
> I experimented with the java.util.Date class and together with an Occurence type which specifies the time format by a Basename following the formatting syntax (e.g. dd.mm.yyyy) we get a way to create time aware TopicMaps.
> 
> I also think that the impact on the API would be relatively small.
> 
> Cheers,
> 
> Harald
> 
> ____________________________________________________
> Aufnehmen, abschicken, nah sein - So einfach ist 
> WEB.DE Video-Mail: http://freemail.web.de/?mc=021200
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila