[sc34wg3] Slides for XTM 2.1 discussion
patrick at durusau.net
Mon Nov 2 08:06:15 CST 2009
Other than your personal suspicion of "confusion" by introduction of a
new version of XTM do you have any other evidence on that point?
The reason I ask is that I quite recently voted on DocBook 5.0, which
has had more than a couple of versions since I first encountered it (I
think it was pre-1.0) and so far as I know neither developers nor the
user community around DocBook have been "confused" by different versions
of the standard.
I think the changes are warranted and merit a new version number.
Hope you are having a great day!
PS: My only concern with an amendment is that the scope be limited to
the issues now before us so we don't unnecessarily subtract time and
resources from TMQL and TMCL.
Steve Pepper wrote:
> I would like to caution against creating a new version of XTM (#1493). As long
> as changes are very minor and backwards compatible, it is better to issue a
> Technical Corrigendum and keep the same version numbering.
> [By "backward compatibility" I of course mean changes that do not render
> existing *documents* invalid. Rendering existing applications non-conformant
> should not be an issue, especially when the changes are minor and the number of
> applications relatively small.]
> Version numbering of specifications is not the same as version numbering of
> software. In the case of software, there are strong arguments for numbering
> every new build. In the case of specifications, there are strong arguments for
> keeping the number of versions to a minimum, viz:
> 1. avoid confusing the user community with multiple versions
> 2. avoid the need for developers to support multiple versions
> My suggestion is to approve whatever changes are deemed necessary and issue a TC
> using the same version number (2.0). Thereafter work to encourage developers of
> existing Topic Maps engines to update their software in order to remain
> Regarding the other proposed changes, I cannot say that it has been demonstrated
> to me that #1460, #1462 or #1459 are show-stoppers that actually prevent users
> from achieving certain tasks. The worst that can be said about them is that they
> make certain (rarely used?) tasks slightly less convenient.
> #1496 is likewise a "nice to have" in the sense that it removes the necessity of
> a workaround but does not actually enable anything that cannot already be done.
> Since it requires changes to the data model as well as the syntax, a convincing
> case should be put forward before any changes are approved.
> In sum, none of these issues seems to justify the confusion caused by creating a
> new version or issuing a TC.
> | -----Original Message-----
> | From: sc34wg3-bounces at isotopicmaps.org [mailto:sc34wg3-
> | bounces at isotopicmaps.org] On Behalf Of Lars Marius Garshol
> | Sent: 29 October 2009 10:18
> | To: Discussion of ISO/IEC 13250 Topic Maps
> | Subject: [sc34wg3] Slides for XTM 2.1 discussion
> | I've prepared a set of slides for discussion of the XTM 2.1 proposal
> | at the ISO meeting in Leipzig:
> | http://www.isotopicmaps.org/sam/xtm-2.1-issues.pdf
> | If you are attending the meeting, *please* study these slides before
> | arriving.
> | Discussion of the issues before the meeting is of course welcome.
> | So if you are not attending the meeting you may want to study these
> | slides anyway, and make your opinions known, by posting them here, in
> | the issue tracker, or by emailing the editors (Graham and yours truly).
> | --Lars M.
> | http://www.garshol.priv.no/tmphoto/
> | http://www.garshol.priv.no/blog/
> | _______________________________________________
> | sc34wg3 mailing list
> | sc34wg3 at isotopicmaps.org
> | http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
More information about the sc34wg3