OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Re: Towards a more modular ODF?


Rob,

Just to pull out one part of your post:

> For 1.3, security enhancements to the Packaging part is something that
> could be delivered faster as a module than the 2-year proposed schedule
> for ODF 1.3 as a whole.

True and packaging is a separate part already.

I don't know of any reason why packaging could not proceed more quickly 
and the other parts reference it when they mature.

Perhaps it was the granularity of your "modules" that were off-putting.

;-)

That would take a lot of work to tease out of Part 1, not that I mind 
but I don't see the advantage (yet).

Hope you are having a great day!

Patrick


On 7/25/2011 8:59 AM, robert_weir@us.ibm.com wrote:
> Patrick Durusau<patrick@durusau.net>  wrote on 07/25/2011 06:35:13 AM:
>
>> From: Patrick Durusau<patrick@durusau.net>
>> To: ODF TC List<office@lists.oasis-open.org>
>> Date: 07/25/2011 06:38 AM
>> Subject: [office] Re: Towards a more modular ODF?
>>
>> Rob,
>>
>> As you know, I have no problems with the general idea of a more modular
>> ODF, particularly when it comes to following other standards as part of
>> becoming more modular.
>>
>> And I think everyone would like to see the next version of ODF, whether
>> an ODF 1.3 or ODF-Next, quicker than we reached ODF 1.2.
>>
>> But before we debate the merits of being more modular, which would take
>> in the concerns about dependencies, where to make divisions, how that
>> impacts the standards process (do we have
>> committee-specification-draft-ODF-part-20?) and other concerns,
>> shouldn't we ask if being more or less modular is really the problem?
>>
> I'm not suggesting that there is "one problem" only, with "one solution".
> Clearly, this is complex.
>
>> That is are we assuming more modular = greater speed and less modular =
>> less speed?
>>
>> I don't see any evidence for either proposition at this point.
>>
>
> For example, with ODF 1.2, OpenFormula. It had an early start and could
> easily have been delivered as a "module" in 2008 or 2009.  We had the
> resources and the draft spec.  But we had to wait for the rest of ODF 1.2
> to catch up.  Yes, in the end, OpenFormula took just as long as everything
> else in ODF 1.2, but this was largely a case of a task taking all
> available time allowed to it.  If OpenFormula could have been delivered as
> a standalone part for ODF 1.2, we would have done that work earlier. There
> was certainly demand for it earlier.
>
>
>> For example, if being more modular would result in faster action, we
>> should be able to point to some supposed separate "module" that is ready
>> to go to ODF 1.3 in the relatively near future. That is some part of ODF
>> whose progress is being retarded by the progress on some other part.
>>
>> Can you name one? I can't.
>>
> For 1.3, security enhancements to the Packaging part is something that
> could be delivered faster as a module than the 2-year proposed schedule
> for ODF 1.3 as a whole.
>
> Change tracking is interesting example.  In the generic form, it would
> work well as a module.  But in the form that extends our current approach,
> it would cut across all modules.
>
> I'd also look at other multi-part standards, say ISO/IEC 29500.  That
> shows some of the benefits and liabilities of a modular approach.  Where
> they had cross-cutting changes, that went across several parts, it
> exploded their work.  But it also allowed finer-grained changes to a
> single part.  It is not a panacea.  Some schemas and specs lend themselves
> to modularization more than others.
>
>
>> To give us a basis for deciding on more or less modularity, let me
>> suggest an addition to our current roadmap.
>>
>> Instead of the current file a bug/proposal by date X methodology, as a
>> TC let's develop a set of features for ODF 1.3/ODF-Next.
>>
>> So that like software projects, open source and otherwise, there is a
>> set of targets and the question becomes one of tracking the resources
>> that are devoted to meeting those targets.
>>
>> Then if some part of those targets begins to lag, we can either decide
>> to devote more resources to it or try to separate it out so it doesn't
>> delay the next release.
>>
>> Being more specific about that features we want for the next release may
>> (no guarantees) prompt others to devote resources to make those features
>> a reality.
>>
>> So, rather than take up your modular question now, my suggestion is that
>> we develop requirements for ODF 1.3/ODF-Next and start putting resources
>> along side those requirements. To put us more on a traditional software
>> project basis.
>>
> This is the question of having a time-boxed schedule or a feature-boxed
> schedule.  But we don't need to be so rigid about this either way.  For
> example, we can have time-boxed CSD's (every 6 months) while having the
> final CSD (the eventual CS) be feature-boxed.
>
>> Hope you are at the start of a great week!
>>
>> Patrick
>>
>> -- 
>> Patrick Durusau
>> patrick@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)
>>
>> Another Word For It (blog): http://tm.durusau.net
>> Homepage: http://www.durusau.net
>> Twitter: patrickDurusau
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

-- 
Patrick Durusau
patrick@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)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]