Menu
▾
▴
tinytim-discuss — Discussions relating to tinyTiM
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(30) |
May
(4) |
Jun
(19) |
Jul
(36) |
Aug
(21) |
Sep
(10) |
Oct
(18) |
Nov
(43) |
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(5) |
Feb
(18) |
Mar
(6) |
Apr
|
May
|
Jun
(6) |
Jul
(21) |
Aug
(47) |
Sep
(3) |
Oct
|
Nov
(5) |
Dec
|
| 2010 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
(14) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Lars H. <he...@se...> - 2008-07-29 09:34:08
|
Hi Stefan, [...] > i did the easy port and now i'm trying to go through (and creating > new) all junit tests. For the unit tests you should use the CXTM test suite and tinyTiM's Canonicalizer. I can help if necessary. The CXTM test suite has the advantage that it is verified by 3rd parties and covers most aspects of importing topic maps. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-29 09:16:58
|
Hi, FYI: i decided to switch to StAX, i found some small StAX implementations and even some for J2ME, so i did the easy port and now i'm trying to go through (and creating new) all junit tests. Stefan Lars Heuer wrote: > Hi Stefan, > >>> Either is okay, I think. StAX seems to be part of Java 6, so the size >>> of the StAX implementations may become less important in the near >>> future. > >> hmm i forgot about this, have to rethink again :-) > > :) We'd have the option to say, that Java 1.5 users have to download a > StAX impl of their choice and 1.6 users can simply use the default > impl. Moving to 1.6 is a bit early, in my opinion. |
|
From: Lars H. <he...@se...> - 2008-07-23 12:07:22
|
Hi Markus, [...] >> Hmmm... maybe we stick with the java.logging for the 1.5 series and wait for >> other opinions and may switch to SLF4J in the 2.0 branch (if TMAPI 2.0 >> become reality). > I could live with that, too, of course--though I'd still say it's better to > propagate good libraries/facades early as long as they're rather > lightweight ;) Okay, I think we'll stick for the time being to Java Logging. But you should be able to redirect that output to SL4J via the "SLF4JBridgeHandler", see <http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html> and <http://www.slf4j.org/legacy.html>. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-21 15:56:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, i prefer waiting for I/O, i hope i can do it this week. stefan Lars Heuer wrote: > Hi all, > > I wonder if we should release the next alpha or even better "1st beta" > version of tinyTiM or if we want to wait for tinyTiM I/O? > > - tinyTiM (the engine itself) is ready for a new release > - .cxtm is ready for a new release > - .mio is ready for a new release > > Best regards, > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIhLB9bsixtqnWg1oRAnffAJ0Zp6/O7ljEgDIwdDw1AQNVMl0CTgCfaOea qgSfV73DaYwrdl8Vc3Kl97g= =iPLi -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-21 13:58:25
|
Hi all, I wonder if we should release the next alpha or even better "1st beta" version of tinyTiM or if we want to wait for tinyTiM I/O? - tinyTiM (the engine itself) is ready for a new release - .cxtm is ready for a new release - .mio is ready for a new release Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-17 09:31:38
|
[SVN commit does not work] > No, via a normal SVN client. Strange, I tried to create an inital > layout, but I get a 403 forbidden msg. Maybe SF is defunct again. Works again, if you update to rev 82, you'll see the initial directory layout for tinytim-io. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-16 16:04:45
|
Hi Stefan, >> Either is okay, I think. StAX seems to be part of Java 6, so the size >> of the StAX implementations may become less important in the near >> future. > hmm i forgot about this, have to rethink again :-) :) We'd have the option to say, that Java 1.5 users have to download a StAX impl of their choice and 1.6 users can simply use the default impl. Moving to 1.6 is a bit early, in my opinion. >> I've never got closely in touch with pull parsing, > i attached an article i wrote about stax some years ago in the > xml&webservices magzin, it reads quickly and give you a small > overview. Merci. >> provide a class for writing XML like StAX or do you want to write the >> XML via SAX or something other? > xmlpull has also an xmlserializer, just have a look at the > tmapi-utils xtmwriter it is already using it. Ah, well, yes. Forgotten :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-16 15:16:40
|
Hi Stefan, [...] > so i propose to just "fix" the stuff that is not working with the > old parser and then we have a lightweight and fast tinytim-io > package (max 100k with parser,xmlpull api, and xtm-parser) > what you think? Either is okay, I think. StAX seems to be part of Java 6, so the size of the StAX implementations may become less important in the near future. But I really do not care, either is okay. I've never got closely in touch with pull parsing, does xmlpull provide a class for writing XML like StAX or do you want to write the XML via SAX or something other? Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-16 14:51:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ok, ill try later, while working throw the tmapi-utils xtm-parser i wrote some years ago, i'm really thinking twice about changing from xmlpull to StAX. dunno why to do it, xmlpull is simple and the xpp3/mxp1 parser is the fastest one at the world. using stax might be more in a jcp/jsr way, but the parsers (e.g. woodstox) are monsters (500k jarsize). so why not using the good old stuff, i think the user wont have a look at inside. so i propose to just "fix" the stuff that is not working with the old parser and then we have a lightweight and fast tinytim-io package (max 100k with parser,xmlpull api, and xtm-parser) what you think? stefan Lars Heuer wrote: > Hi Stefan, > > [...] >> irgendwie kann ich mit meinem eclipse kein verzeichniss im svn >> erstellen, hast du das mit der sf.net >> website gemacht? > > No, via a normal SVN client. Strange, I tried to create an inital > layout, but I get a 403 forbidden msg. Maybe SF is defunct again. > > Best regards, > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfgmybsixtqnWg1oRAlJcAJ9E28JnXts7KLkfB0crBZNseLAskACgjaPa 0n+wEYoOn3wv1Tlyj9mXhu0= =mCfM -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-16 14:46:42
|
[...] > No, via a normal SVN client. Strange, I tried to create an inital > layout, but I get a 403 forbidden msg. Maybe SF is defunct again. Even a "normal" commit does not work. I changed the CHANGES.txt file for testing purposes and tried to commit that change but get the same error. I guess we've to wait. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-16 14:34:51
|
Hi Stefan, [...] > irgendwie kann ich mit meinem eclipse kein verzeichniss im svn > erstellen, hast du das mit der sf.net > website gemacht? No, via a normal SVN client. Strange, I tried to create an inital layout, but I get a 403 forbidden msg. Maybe SF is defunct again. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-16 13:36:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi lars, irgendwie kann ich mit meinem eclipse kein verzeichniss im svn erstellen, hast du das mit der sf.net website gemacht? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIffgNbsixtqnWg1oRAquNAJsHkAomyHW+nbsRIm2S456DwsZVVACeP5FA FU+5dDs1LmGKsidL9p6itfc= =6ULp -----END PGP SIGNATURE----- |
|
From: SourceForge.net <no...@so...> - 2008-07-14 02:20:14
|
Bugs item #2004624, was opened at 2008-06-27 23:48 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=631664&aid=2004624&group_id=102341 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: I/O Group: None >Status: Closed Resolution: Later Priority: 9 Private: No Submitted By: Stefan Lischke (lischke2) Assigned to: Lars Heuer (lheuer) Summary: Roles are not imported Initial Comment: Roles of Associations are not imported. the startRole() or startPlayer() methods of the MapInputHandler are never called. See org.tinytim.io.ParseRolesTest.testBugImportRoles2() btw. its not so good to debug, and understand code, if there is code used, from which i can not see the code (semagia-mio) ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-07-14 02:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Lars Heuer (lheuer) Date: 2008-06-29 12:20 Message: Logged In: YES user_id=399396 Originator: NO This seems to be a MIO problem; the external lib has to be fixed, not tinyTiM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=631664&aid=2004624&group_id=102341 |
|
From: Lars H. <he...@se...> - 2008-07-02 16:41:42
|
[...] >> So do we have to provide the parse(tmsystem,input) for xtm 1.0 ? > No, not necessarily; parsing XTM 1.0 not very different from XTM 2.0, [...] Maybe I should send my mails firstly to myself so I can cut them down to one sentence and *then* send them to the ml. ;) To cut the long story short: It's always okay to let the user override the document IRI regardless of the concrete Topic Maps syntax, because it is such a fragile thing that is never stable and cannot be used to get back stable topic identities. In XTM 1.0 / LTM 1.x the document IRI may be overridden, though. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-02 16:32:44
|
Hi Stefan, > So do we have to provide the parse(tmsystem,input) for xtm 1.0 ? No, not necessarily; parsing XTM 1.0 not very different from XTM 2.0, first, the document IRI is used. If you find a xml:base in the XTM 1.0 file, that xml:base is used. Note, that a XTM 1.0 file may contain any number of xml:base attributes. You have to take care that you use the *current* xml:base. So, it would be pretty okay if the user wants to override the (initial) document IRI, but it may not be used for all Topic Maps constructs, because the xml:base overrides the document IRI. Yes, that sucks, and this was one of the reasons why xml:base is not used in XTM 2.0. :) Example: If I have a topic map "mymap.xtm" and I place it into the directory /home/lars/maps, the document IRI would be <file:///home/lars/maps/mymap.xtm> but it would be okay, if I dictate that the document IRI <http://www.semagia.com/maps/mymap.xtm> should be used. But even if I dictate that, I cannot assume that every local id is resolved against that IRI, because xml:base may override my document IRI with i.e. <http://tinytim.sf.net/>, so some topics may use <http://tinytim.sf.net/> as base IRI. Complicated stuff. :) But XTM 2.0 is easier to read and to serialize, maybe you want to start with XTM 2.0 and postpone XTM 1.0. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-02 16:17:19
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So do we have to provide the parse(tmsystem,input) for xtm 1.0 ? Lars Heuer wrote: > Hi Stefan, > > [...] >> correct me if i'm wrong, and don't blame me, i did not work with tm >> for quite some time, but isn't the document IRI contained in the >> file? > > In XTM 1.0 it may be contained in the file (xml:base), and LTM > provides also a #BASEURI directive, but this isn't the case for > "modern" Topic Maps syntaxes. The IRI of the document is used or the > application has to provide a document IRI. > > C.f. XTM 2.0: <http://www.isotopicmaps.org/sam/sam-xtm/#d0e361> > > 4.2. Deserialization > [...] > > The input to the deserialization process is: > [...] > * An absolute IRI. This is the IRI from which the XTM document was > retrieved, known as the document IRI. This IRI shall always be > provided, as it is necessary in order to assign the item > identifiers of the topic items created during deserialization. If > the XTM document was not read from any particular IRI the > application is responsible for providing an IRI considered > suitable. > [...] > > > Best regards, > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa6jUbsixtqnWg1oRAoopAJ4p4lgMWYZ+1c4QpKOpNLlu8/2+uACfUJRC s4Uhf6w6MpY1Xn5bihHQ958= =+kbr -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-02 16:05:50
|
Hi Stefan, [...] > correct me if i'm wrong, and don't blame me, i did not work with tm > for quite some time, but isn't the document IRI contained in the > file? In XTM 1.0 it may be contained in the file (xml:base), and LTM provides also a #BASEURI directive, but this isn't the case for "modern" Topic Maps syntaxes. The IRI of the document is used or the application has to provide a document IRI. C.f. XTM 2.0: <http://www.isotopicmaps.org/sam/sam-xtm/#d0e361> 4.2. Deserialization [...] The input to the deserialization process is: [...] * An absolute IRI. This is the IRI from which the XTM document was retrieved, known as the document IRI. This IRI shall always be provided, as it is necessary in order to assign the item identifiers of the topic items created during deserialization. If the XTM document was not read from any particular IRI the application is responsible for providing an IRI considered suitable. [...] Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-02 15:55:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 correct me if i'm wrong, and don't blame me, i did not work with tm for quite some time, but isn't the document IRI contained in the file? Lars Heuer wrote: > [...] >>> but if i don't know the document IRI? just parsing a file from the >>> web/p2p network. So i think, the first style is needed for this >>> case. > >> I think the document IRI is overestimated. IMO it would be better if > [...] > > Example: If you send me a file "mymap.ctm" with the following content: > > tinytim. > > and I place it into the directory "/home/lars/maps/" and I read it > into my engine, I get a topic with the item identifier > <file:///home/lars/maps/mymap.ctm#tinytim>. > > And if I send that file to my friend Donald Duck (assuming that > Duckburg has a broadband connection ;)) and he places that file into > the directory "/home/donald/", and he reads that file in, he gets a > topic with the item identifier > <file:///home/donald/mymap.ctm#tinytim>. > > > You see, the local identifiers are never stable. If you want, that I > get back exactly the same topic map, you have to tell me your document > IRI and I can provide that document IRI to my TopicMapReader. > > Best regards, > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa6PQbsixtqnWg1oRAh8ZAJ0eum4WKNRnDLcRn6NwH6dPD5HiUACgmF0b EGX2kTm7RcqODelE6/FCkwI= =JYHv -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-02 15:50:37
|
[...]
>> but if i don't know the document IRI? just parsing a file from the
>> web/p2p network. So i think, the first style is needed for this
>> case.
> I think the document IRI is overestimated. IMO it would be better if
[...]
Example: If you send me a file "mymap.ctm" with the following content:
tinytim.
and I place it into the directory "/home/lars/maps/" and I read it
into my engine, I get a topic with the item identifier
<file:///home/lars/maps/mymap.ctm#tinytim>.
And if I send that file to my friend Donald Duck (assuming that
Duckburg has a broadband connection ;)) and he places that file into
the directory "/home/donald/", and he reads that file in, he gets a
topic with the item identifier
<file:///home/donald/mymap.ctm#tinytim>.
You see, the local identifiers are never stable. If you want, that I
get back exactly the same topic map, you have to tell me your document
IRI and I can provide that document IRI to my TopicMapReader.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Lars H. <he...@se...> - 2008-07-02 15:26:40
|
Hi Stefan, [...] > but if i don't know the document IRI? just parsing a file from the web/p2p network. > So i think, the first style is needed for this case. I think the document IRI is overestimated. IMO it would be better if the user has the possibility to provide an IRI which is used to override the document IRI. The document IRI is "just" used to resolve IRIs against. If the user wants stable IRIs, she should should use (absolute) subject identifiers / locators. If the document IRI is unknown or should be overridden, the user simply sets the IRI which should be used to resolve IRIs against. [...] >> After that, the topic map "tm" would contain the content from the XTM >> source and the LTM source. > but what about clashes? is there a merging? when there is a merge, Yes, of course, there is always merging, even if you read a single topic map. No Topic Maps syntax mandates that the document contains a merged topic map (well, CXTM is an exception, these topic maps are always merged). You have to look up topics all the time. If a topic is read and it is equal to an existing topic, you merge them transparently; no user interaction necessary. And I'd do the same if the user imports serialized topic map into an existing topic map. The user expects that merging is done, she cannot assume that topics do not merge. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Stefan L. <li...@ap...> - 2008-07-02 15:03:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, > I don't care. How about Writer / Reader? Maybe with "TopicMap" as > prefix to distinguish it better from the Java io.Reader / .io.Writer: > TopicMapReader, TopicMapWriter. +1 great idea to use java io style names >> then we have to talk about the interfaces. i'd prefer the tmapi-utils way [...] > If the user wants that the topic map is accessible under the same IRI > as the the document IRI, she can use the document IRI to create the > topic map. but if i don't know the document IRI? just parsing a file from the web/p2p network. So i think, the first style is needed for this case. > to add more content to an *existing* topic map. Importing more topic > map content into an existing topic map should usually be faster than > letting the TMReader create a topic map, merge it with an existing > topic map and to delete the topic map the TMReader has created. OK i got your point, lets do both read(tmsystem,input) read(tm, input) [...] > After that, the topic map "tm" would contain the content from the XTM > source and the LTM source. but what about clashes? is there a merging? when there is a merge, then the user must clearly see it and invoke it from outside calling tm.merge. and setting the right merge properties first. so of there is a "hidden" merge, i would recommend only use approach a and force the user to call merge later. If someone wants some handy shortcut methods he could write it himself. the core api schould be atomar. stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa5ejbsixtqnWg1oRAs7/AJ0SYP/FSpSxYTD3Sp6oGOwFB3sIfgCfVJDh aBLlupI9U4eSsODBxckfCtI= =+8fb -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-02 14:14:38
|
[...] >> TopicMapSystem tmsystem; >> TopicMap tm = parser.parse(tmsystem, file) >> or mio way >> TopicMapSystem tmsystem; >> TopicMap tm = tmsystem.createTopicmap(???,???) >> tm = parser.parse(tm, file) [...] > The latter style allows the user to create a topic map and then [...] ... and the latter style wouldn't make the first style impossible. We can create a TopicMapImportUtil (cannot come up with a better name), which takes a TopicMapSystem, a deserializer and a File / Stream and it creates the topic map and imports the content from the source and returns that filled topic map. Not sure if that is necessary, though. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2008-07-02 12:53:37
|
Hi Stefan,
[...]
> next thing i wanna talk about is naming of:
> serializer/deserialize (i misstyped it 2 times while writing :-) or
> writer/parser
I don't care. How about Writer / Reader? Maybe with "TopicMap" as
prefix to distinguish it better from the Java io.Reader / .io.Writer:
TopicMapReader, TopicMapWriter.
> then we have to talk about the interfaces. i'd prefer the tmapi-utils way
> TopicMapSystem tmsystem;
> TopicMap tm = parser.parse(tmsystem, file)
> or mio way
> TopicMapSystem tmsystem;
> TopicMap tm = tmsystem.createTopicmap(???,???)
> tm = parser.parse(tm, file)
> while using this i did not know what to insert in ???,??? cause its
> overwritten by the parser, so the first way is better in my view.
> let the parser call createTopicMap
Actually, I'd prefer the latter (maybe that's the reason, why it is
handled that way in MIO ;)).
If the user wants that the topic map is accessible under the same IRI
as the the document IRI, she can use the document IRI to create the
topic map. IMO the latter style is nice because it would be possible
to add more content to an *existing* topic map. Importing more topic
map content into an existing topic map should usually be faster than
letting the TMReader create a topic map, merge it with an existing
topic map and to delete the topic map the TMReader has created.
The latter style allows the user to create a topic map and then
TopicMapReader reader = new XTMTopicMapReader();
reader.read(tm, file)
reader = new LTMTopicMapReader();
reader.read(tm, file2);
After that, the topic map "tm" would contain the content from the XTM
source and the LTM source.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Stefan L. <li...@ap...> - 2008-07-02 12:35:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 for plain constructor next thing i wanna talk about is naming of: serializer/deserialize (i misstyped it 2 times while writing :-) or writer/parser then we have to talk about the interfaces. i'd prefer the tmapi-utils way TopicMapSystem tmsystem; TopicMap tm = parser.parse(tmsystem, file) or mio way TopicMapSystem tmsystem; TopicMap tm = tmsystem.createTopicmap(???,???) tm = parser.parse(tm, file) while using this i did not know what to insert in ???,??? cause its overwritten by the parser, so the first way is better in my view. let the parser call createTopicMap what you thing? Lars Heuer wrote: > Hi Stefan, > >> a sounds good, but do we need an IOFactory? or let the user simple call > >> new XTM20Serializer(...) > > IMO for simplicity > > Serializer ser = new XTM20Serializer(); > > is enough. A factory would be an overkill, otherwise we could also use > MIO ;) > > Best regards, > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIa3TMbsixtqnWg1oRArnUAJ9nrllwLFNzyYILQxhdYdvdol3iqACbBc7Z WCgrZI1CO57XmRDoOsVdUxs= =vXKQ -----END PGP SIGNATURE----- |
|
From: Lars H. <he...@se...> - 2008-07-02 12:21:00
|
Hi Stefan,
> a sounds good, but do we need an IOFactory? or let the user simple call
> new XTM20Serializer(...)
IMO for simplicity
Serializer ser = new XTM20Serializer();
is enough. A factory would be an overkill, otherwise we could also use
MIO ;)
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
7 messages has been excluded from this view by a project administrator.
