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: Hannes N. <h.n...@go...> - 2009-08-14 12:03:11
|
Hi Lars, I will look into it, but not before monday, need to finish some other Onotoa stuff first. regards Hannes On Fri, Aug 14, 2009 at 1:55 PM, Lars Heuer<he...@se...> wrote: > Hi Hannes, > > I added some docs to voc.TMCL (rev. 347) and deprecated some constants > (they refer to the new constant name). I am not sure if you use them > for Onotoa. If you don't use them, you can remove them (although we > have to fix the TMCLPreprocessor since it uses some deprecated > constants). > > I am unsure what to do with tmcl:scope-type. I cannot find the PSI in > the current draft. I believe it is replaced with > tmcl:scope-constraint, but I am not sure since I didn't look at the > previous drafts. > > Best regards, > Lars > -- > Semagia > <http://www.semagia.com> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > tinyTiM-discuss mailing list > tin...@li... > https://lists.sourceforge.net/lists/listinfo/tinytim-discuss > -- Onotoa - Simply create your Topic Maps schemas. http://onotoa.topicmapslab.de http://www.topicmapslab.de/people/Hannes_Niederhausen |
|
From: Lars H. <he...@se...> - 2009-08-14 11:59:55
|
Hi all, >> It seems that I've forgotten to submit code changes and nobody >> claimed. :( [...] > No, let's put it this way: We (including me, myself, and I) silently > agreed to grant you a 30 hour grace period before starting to rant. >:) Not sure if I exceeded the deadline, but mio builds now. :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-08-14 11:50:24
|
Hi Hannes, I added some docs to voc.TMCL (rev. 347) and deprecated some constants (they refer to the new constant name). I am not sure if you use them for Onotoa. If you don't use them, you can remove them (although we have to fix the TMCLPreprocessor since it uses some deprecated constants). I am unsure what to do with tmcl:scope-type. I cannot find the PSI in the current draft. I believe it is replaced with tmcl:scope-constraint, but I am not sure since I didn't look at the previous drafts. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-08-13 15:12:58
|
Hi Markus,
[...]
> Then, another possibility would be
> "tinytim-2.0.0a5-mio-2.0.0a5.jar" (in
> which case we maybe could even omit the 'meta' prefix).
Good idea, I like it. :) If nobody comes up with a better scheme, I'll
use
tinytim-{engine-version}-mio-{mio-version}.jar
for the "meta" package.
... and once I've finished console and schema, I'll add a meta meta
package
tinytim-{engine-version}-mio-{mio-version}-schema-{schema-version}-console-{console-version}.jar
and all permutations of it. ;)))
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Markus U. <mar...@gm...> - 2009-08-13 15:02:36
|
Hi Lars, >> I'd simply concatenate the versions as follows: >> "tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here, >> because there's also tinytim-console, tinytim-schema etc.) >> > Okay, but the scheme would look like: > > tinytim-meta-2.0.0a5-2.0.0a5.jar You're right, I mixed up the versions of tinytim-mio and semagia-mio. Still, this doesn't look too bad. Then, another possibility would be "tinytim-2.0.0a5-mio-2.0.0a5.jar" (in which case we maybe could even omit the 'meta' prefix). Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-13 14:51:48
|
Hi Markus, [...] > I'd simply concatenate the versions as follows: > "tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here, > because there's also tinytim-console, tinytim-schema etc.) Thanks for the hint that these sub projects have to be maintained. ;) > This way, the engine version 'dominates' and it also shouldn't confuse > users, because it would still mean that a 'larger' combined version Okay, but the scheme would look like: tinytim-meta-2.0.0a5-2.0.0a5.jar which implies the tinytim version 2.0.0a5 and tinytim-mio 2.0.0a5. If tinytim-mio a6 is released, we get: tinytim-meta-2.0.0a5-2.0.0a6.jar > (the stituation where a newer engine version > requires an older mio version shouldn't be likely to happen, right?) Unlikely. :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Markus U. <mar...@gm...> - 2009-08-13 14:45:35
|
Hi all,
> For (b) this could be more difficult. Maybe the engine version number
> should rule and for each -mio release a patch level is added?
>
> tinytim-complete-{version}.sp1.jar
>
> Hmmm.... better ideas? :)
>
> The goal of the additional distributions should be to ease the start
> with tinyTiM and not to confuse users... ;)
>
I'd simply concatenate the versions as follows:
"tinytim-meta-2.0.0a5-0.9.5.jar" (I prefer "meta" over "complete" here,
because there's also tinytim-console, tinytim-schema etc.)
This way, the engine version 'dominates' and it also shouldn't confuse
users, because it would still mean that a 'larger' combined version
refers to a newer archive (the stituation where a newer engine version
requires an older mio version shouldn't be likely to happen, right?)
Ad astra, Markus
|
|
From: Lars H. <he...@se...> - 2009-08-13 14:34:49
|
Hi Hannes,
>> For the record:
>> +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets
>> updated with each respective release from me ;)
> and +1 from me.
> Question is how would the version looklike for this distribution ?
:) Good question. For (a) could be something like
tinytim-mio-all-{version}.jar where {version} represents the current
tinytim-mio version.
For (b) this could be more difficult. Maybe the engine version number
should rule and for each -mio release a patch level is added?
tinytim-complete-{version}.sp1.jar
Hmmm.... better ideas? :)
The goal of the additional distributions should be to ease the start
with tinyTiM and not to confuse users... ;)
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Markus U. <mar...@gm...> - 2009-08-13 14:29:54
|
Lars Heuer schrieb: > It seems that I've forgotten to submit code changes and nobody > claimed. :( > But that's only because you noticed it early. :) No, let's put it this way: We (including me, myself, and I) silently agreed to grant you a 30 hour grace period before starting to rant. >:) Ad astra, Markus |
|
From: Hannes N. <h.n...@go...> - 2009-08-13 14:26:31
|
> For the record: > +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets > updated with each respective release from me ;) and +1 from me. Question is how would the version looklike for this distribution ? regards Hannes -- Onotoa - Simply create your Topic Maps schemas. http://onotoa.topicmapslab.de http://www.topicmapslab.de/people/Hannes_Niederhausen |
|
From: Markus U. <mar...@gm...> - 2009-08-13 14:16:23
|
Hi Lars, >> ad b) Why should this mean that tinytim and tinytim-mio releases >> wouldn't be independent anymore? Wouldn't the meta-release simply >> include/reference the respective latest official releases? >> > You're right. Although the meta distribution would either be outdated > if we release tinytim-mio (without a new release of tinytim) or the > meta distribution has to be updated at each release of tinytim-mio and > tinytim. > I think, I'll offer (a) first and maybe (b) later. > For the record: +1 for a "v.(tinytim)/v.(tinytim-mio)" meta distribution which gets updated with each respective release from me ;) Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-13 14:10:52
|
[...] > It seems that I've forgotten to submit code changes and nobody > claimed. :( > I'll fix that asap. Although it's easy to fix (AbstractXTMTopicMapReader needs access to the underlying topic map), this has to wait till tomorrow since I don't have the code here. Sorry and best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-08-13 14:06:21
|
Hi all, It seems that I've forgotten to submit code changes and nobody claimed. :( I'll fix that asap. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-08-13 13:57:43
|
Hi Markus, >> [...] What do you think? Would >> a) tinytim-mio-batteries-included >> b) meta-tinytim (the engine and mio) >> be a good addition to the current distribution model? > ad a) Maybe it would make life at tiny litte bit easier for those who > want to try out tinytim _fast_ (e.g., after reading a short TM(API) [...] Yes, I have that kind of users in mind. And those who want to use tinyTiM in Applets. I am not sure if I'd use that distribution, it would just be an offer for users who want to place two libs in the CP and start with TMAPI, as you stated above. > ad b) Why should this mean that tinytim and tinytim-mio releases > wouldn't be independent anymore? Wouldn't the meta-release simply > include/reference the respective latest official releases? You're right. Although the meta distribution would either be outdated if we release tinytim-mio (without a new release of tinytim) or the meta distribution has to be updated at each release of tinytim-mio and tinytim. I think, I'll offer (a) first and maybe (b) later. Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Markus U. <mar...@gm...> - 2009-08-13 13:47:21
|
Hi Lars, Lars Heuer schrieb: > [...] What do you think? Would > a) tinytim-mio-batteries-included > b) meta-tinytim (the engine and mio) > be a good addition to the current distribution model? ad a) Maybe it would make life at tiny litte bit easier for those who want to try out tinytim _fast_ (e.g., after reading a short TM(API) intro with code fragments), but personally I'd never use it (cf. the Ontopia repository discussion regarding (rather well-known) third party libraries like slf4j -- they could either be automatically retrieved or at least a short description where to obtain them by means of 2-3 mouse clicks should IMHO be enough). ad b) Why should this mean that tinytim and tinytim-mio releases wouldn't be independent anymore? Wouldn't the meta-release simply include/reference the respective latest official releases? Ad astra, Markus |
|
From: Lars H. <he...@se...> - 2009-08-13 11:53:19
|
Hi all, I wonder if it makes sense to add another tinyTiM distribution (especially for mio). While I like the current distribution (just pick the mio libs you're actually using, and update the mio libs independently of tinytim-mio), I think it might be nice to have one jar with batteries included. That lib would include all semagia-mio dependencies, so the user needs only the slf4j-libs and (if validation is necessary), the jing lib. I could also include the slf4j-libs, if that's worth. Maybe I could also add another (meta) distribution which includes the engine and the tinytim-mio package. The disadvantage would be, that releasing tinytim-mio and tinytim wouldn't be independent anymore. What do you think? Would a) tinytim-mio-batteries-included b) meta-tinytim (the engine and mio) be a good addition to the current distribution model? Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Hannes N. <h.n...@go...> - 2009-08-13 11:41:29
|
Great, thank you. regards Hannes On Thu, Aug 13, 2009 at 1:37 PM, Lars Heuer<he...@se...> wrote: > Hi all, > > [...] >> I planned to use filesets anyway to get rid of the repeated >> <classpath><pathelement/></classpath> statements. > > I updated the build script (rev. 345) to match any > tinytim-version-with-a-strange-snapshot-name.jar > > Best regards, > Lars > -- > Semagia > <http://www.semagia.com> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > tinyTiM-discuss mailing list > tin...@li... > https://lists.sourceforge.net/lists/listinfo/tinytim-discuss > -- Onotoa - Simply create your Topic Maps schemas. http://onotoa.topicmapslab.de http://www.topicmapslab.de/people/Hannes_Niederhausen |
|
From: Lars H. <he...@se...> - 2009-08-13 11:32:27
|
Hi all, [...] > I planned to use filesets anyway to get rid of the repeated > <classpath><pathelement/></classpath> statements. I updated the build script (rev. 345) to match any tinytim-version-with-a-strange-snapshot-name.jar Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Lars H. <he...@se...> - 2009-07-24 11:38:52
|
Hi Hannes,
[...]
>> <path id="compile.classpath.tmapi2">
>> <fileset dir="${lib.dir}/3rdparty/tm-engine/tinytim20">
[...]
>> </fileset>
>> </path>
>>
> And that is what I wanted/needed. Great :)
> Could we change the build.xml of mio like that?
Yes, good idea. I am not sure if I'll be able to do it today / this
weekend but feel free to modify the mio build. :)
I planned to use filesets anyway to get rid of the repeated
<classpath><pathelement/></classpath> statements.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
|
|
From: Hannes N. <h.n...@go...> - 2009-07-24 06:44:01
|
Hi,
> I actually like the current naming scheme ;)
I also do, really.
> @Hannes: In order to remedy the problem mentioned above, I use fileset
> definitions instead of hard-coded names (which is far more convenient as
> long as there's only one version of a library in the search path), e.g.,
>
> <path id="compile.classpath.tmapi2">
> <fileset dir="${lib.dir}/3rdparty/tm-engine/tinytim20">
> <include name="tmapi-2*.jar" />
> <include name="tinytim-mio-2*.jar" />
> <!-- needed because of TinyTimMapInputHandler -->
> <include name="tinytim-2*.jar" />
> </fileset>
> </path>
>
And that is what I wanted/needed. Great :)
Could we change the build.xml of mio like that?
regards
Hannes
--
Onotoa - Simply create your Topic Maps schemas.
http://onotoa.topicmapslab.de
http://www.topicmapslab.de/people/Hannes_Niederhausen
|
|
From: Markus U. <mar...@gm...> - 2009-07-23 23:16:59
|
Lars Heuer schrieb:
> Hi Hannes,
>
>> Is it possible to remove the snapshot part of the tinyTiM-2.0.0a5 jar?
>> Right now it is necessary to edit the build.xml of tinyTiM-mio for
>> every new tinyTiM build, which is a bit annoying.
>>
> It is. :)
> Just remove the hash in front of
> #release_type=
> in the build.properties.
>
> I am open to better ideas how to distinguish between official builds
> and snapshots, though. :)
>
I actually like the current naming scheme ;)
@Hannes: In order to remedy the problem mentioned above, I use fileset
definitions instead of hard-coded names (which is far more convenient as
long as there's only one version of a library in the search path), e.g.,
<path id="compile.classpath.tmapi2">
<fileset dir="${lib.dir}/3rdparty/tm-engine/tinytim20">
<include name="tmapi-2*.jar" />
<include name="tinytim-mio-2*.jar" />
<!-- needed because of TinyTimMapInputHandler -->
<include name="tinytim-2*.jar" />
</fileset>
</path>
Ad astra, Markus
|
|
From: Lars H. <he...@se...> - 2009-07-23 17:38:05
|
Hi all, The tinyTiM project proudly announces the availability of a new release of the tinyTiM Topic Maps engine. This release implements the TMAPI 2.0 a2 interfaces. You can download it from tinyTiM's project page <http://sourceforge.net/projects/tinytim> Changes: * JTMTopicMapReader / JTMTopicMapWriter implement the new JSON Topic Maps specification (<http://www.cerny-online.com/jtm/1.0/> * LTMTopicMapReader: Configurable reification handling * Updated to TMAPI 2.0a2 * Updated TMCL constants (implemented by Hannes Niederhausen) Bugfixes: --------- * XTM 2.0 importer sets the reifier of a merged-in topic map to the master topic map. Correct behaviour: Just import the topic but loose the reified topic map. * Validation of XTM 1.0 and 2.0 sources against a RELAX-NG schema did not work in all cases, fixed in "semagia-mio-xtm-0.9.4.jar" * XTM 1.0 <mergeMap/> didn't work, fixed * Bug #2560821 -- XTM 1.0 serializer uses wrong element for type reported by Jens Rummler * Bug #2540490 -- Using QName in isa/ako throws syntax error (CTM libs) reported by Stefan Kesberg * XTM 1.0 writer forgot to add a <variantName/> element to the output. * Bug #2812460 -- Port the Check class from Ontopia back to tinyTiM * Bug #2809821 -- Ensure same topic map constraint * Bug #2561306 -- Move TinyTimMapInputHandler to the core * Bug #2824834 -- Reifier at duplicate construct fails * Bug #2824837 -- Same iid at a duplicate statement does not work Thanks to Hannes for his work. :) Best regards, Lars -- Semagia <http://www.semagia.com/> |
|
From: Lars H. <he...@se...> - 2009-07-23 12:57:15
|
Hi Hannes, > Is it possible to remove the snapshot part of the tinyTiM-2.0.0a5 jar? > Right now it is necessary to edit the build.xml of tinyTiM-mio for > every new tinyTiM build, which is a bit annoying. It is. :) Just remove the hash in front of #release_type= in the build.properties. I am open to better ideas how to distinguish between official builds and snapshots, though. :) Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Hannes N. <h.n...@go...> - 2009-07-23 12:47:58
|
Hi, Is it possible to remove the snapshot part of the tinyTiM-2.0.0a5 jar? Right now it is necessary to edit the build.xml of tinyTiM-mio for every new tinyTiM build, which is a bit annoying. regards Hannes -- Onotoa - Simply create your Topic Maps schemas. http://onotoa.topicmapslab.de http://www.topicmapslab.de/people/Hannes_Niederhausen |
|
From: SourceForge.net <no...@so...> - 2009-07-23 12:27:20
|
Bugs item #2824837, was opened at 2009-07-21 16:41 Message generated for change (Comment added) made by lheuer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=631664&aid=2824837&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: tinyTiM 2.x >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Lars Heuer (lheuer) Assigned to: Lars Heuer (lheuer) Summary: Same iid at a duplicate statement does not work Initial Comment: <http://code.google.com/p/ontopia/issues/detail?id=91> MapHandler should check if the statement which should get the iid is a duplicate ---------------------------------------------------------------------- >Comment By: Lars Heuer (lheuer) Date: 2009-07-23 14:27 Message: Fixed in rev. 329 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=631664&aid=2824837&group_id=102341 |
7 messages has been excluded from this view by a project administrator.
