Minutes of teleconference meeting on 2010-05-26

[robert_weir at us.ibm.com]

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.

Regards,

-Rob