Minutes of teleconference meeting on 2010-05-26

[Francis Cave]

Rob

You make several good points.

I agree that SC 34 members should think very carefully before proposing
extensions to any standard that are either (a) outside the general scope of
SC 34's work or (b) too narrow in scope (e.g. of interest only to a single
industry or a single country). 

In either case it seems to me that, provided the base standard provides some
reasonable extension mechanism, it should not be necessary for the base
standard to be revised. The obvious approach is to develop a "profile" based
upon the base standard, probably including additional semantics and
structure that uses whatever extension mechanisms are in the base standard.
Such a profile would necessarily reference the base standard, but there
would be no necessity for the base standard to reference the profiles. 

Such profiles could be developed within SC 34, but they could equally be
developed by other SCs, by national standards bodies, by OASIS, or indeed by
any body representing a community of users of the base standard that wish to
profile its use for their own purposes.

You could, of course, argue that such profiles are not true extensions,
because extensions must necessarily involve adding functionality to the base
standard. But I think that extension is the best term nevertheless.

That is not to say that, if a profile became widely used, the additional
semantics and structure that it defines could not be absorbed into the base
standard. This could happen either by normatively referencing the profile
from the base standard, or by incorporating the text of the profile directly
into the base standard. 

A question: if OASIS were to develop such an extension profile of ODF,
defining the structure and semantics of some schema in an external
namespace, with some specific normative behaviour defined for producers and
consumers, would it be possible to refer to this from the ODF standard
without a technical change to the base standard? I am assuming of course
that there would be no requirement on implementers of the base standard
(whether producers or consumers) to behave in any particular way with
respect to extension elements, unless they chose to implement the extension
profile as well.

Regards,

Francis



> -----Original Message-----
> From: sc34wg6-bounces at vse.cz [mailto:sc34wg6-bounces at vse.cz] On Behalf
> Of robert_weir at us.ibm.com
> Sent: 01 June 2010 16:47
> To: sc34wg6 at vse.cz
> Subject: Re: Minutes of teleconference meeting on 2010-05-26
> 
> 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
> 
> 
> 
> _______________________________________________
> sc34wg6 mailing list
> sc34wg6 at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg6