Minutes of teleconference meeting on 2010-05-26
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Tue Jun 1 17:46:41 CEST 2010
sc34wg6-bounces at vse.cz wrote on 06/01/2010 05:13:31 AM:
> Dear members of SC 34/WG 6
> I attach minutes of the teleconference meeting held on 2010-05-26.
> May I draw your attention to the Action associated with item 4.1 in
> the minutes, requesting all WG 6 members to consider the question of
> whether and how extensions to ISO/IEC 26300 should be made possible.
> This topic will be a major item on the agenda for the next
> teleconference meeting, which Is scheduled for 2010-06-23 at 13:00 UTC.
For 4.1, I think I'd first ask, "How do we know this is an extension?"
For ODF for 5 years now, augmenting the feature set expressed by ODF has
been done by revision of the standard, not by an external extension
mechanism. That approach has known advantages as well as disadvantages
that should be considered.
In my thinking this is a factoring question, and you would want to look at
indications of inter-module cohesion as well as intra-module coupling. If
the new functionality is only loosely coupled with the existing features
of ODF, but is itself highly cohesive, then treat it as an extension. If
on the other hand, it is deeply intertwined with several features of ODF,
or is itself not very cohesive, then handle it via revision of ODF.
Also, keep in mind how broadly applicable the feature would be. I think
we'd agree that an enhancement to accessibility is broadly applicable and
would be best done as a core feature rather than an extension even if it
could be easily expressed as an extension. But a feature that only
benefits, say the petroleum offshore drilling industry in the UK, might be
treated as an extension, perhaps one in another SC altogether. A question
to ask is whether the new feature is solidly in the scope of the original
standard, or whether it tugs it into a different domain.
Finally, keep in mind the maintenance implications. If you try to do a
poorly factored extension as a separate standard, you create a maintenance
nightmare if the extension is tightly coupled with features that are
simultaneously being corrected or revised in the core ODF specification.
In any case, for these specific CJK features noted from the workshop, some
of these are already on the ODF TC's ODF-Next list, based on previous
proposals from Justsystems and RedFlag Office. Personally, I would
consider CJK support to be an intended core feature of ODF, not an
extension, as evidenced by our current inclusion of CJK features like Ruby
annotations and Asian layout grids.
More information about the sc34wg6