RE: [office] Re: ODF Conformance

[robert_weir@us.ibm.com]

Hi Doug,

I don't want to leave this offer unacknowledged.  I think this is worth 
doing, along the lines of the "least power" thought I sent earlier. 
customXML is a targeted approach, and that is better, IMHO, than bringing 
out the more powerful nuclear death ray every time.

As mentioned before, I'd like to get a better sense of what extensibility 
features vendors really need, and in what specific areas, and see if some 
combination of targeted mechanisms will handle them. 

My understanding is that customXML is not so much for vendor application 
extensions, but for end-user or 3rd party extensions, to align with 
in-house or vertical industry XML vocabularies.  Is that a fair 
representation?  That's fine too. In any case, before the TC can get far 
with customXML, you'll need to see what approvals you need from your guys 
before you can contribute the relevant pages of the OOXML standard to the 
ODF TC.  I think we would need a formal contribution to satisfy the OASIS 
IPR rules.

I really don't want to delay ODF 1.2, since I am already being accused of 
running a "death march", but if enough members feel strongly about this, 
we do have options:

1) Insert some additional normative language about extensibility 
mechanisms, included some targeted approaches into ODF 1.2.  Maybe if we 
get the main uses cases covered by targeted approaches we can remove or at 
least deprecate the "nuclear death ray gun" mechanism?

2) Or, we could add a non-normative appendix on extensibility in ODF 1.2, 
outlining the various existing mechanisms and suggesting best practices. 
This could also be done in a separate document along the lines of what we 
did with the Accessibility Guidelines.

3) We could, if there was strong interest, strip out all of the 
extensibility mechanisms in Part 1 of ODF 1.2 and put them into a new Part 
4, to follow the other 3 parts, giving us more time and room to work out a 
more comprehensive solution.

4) Kick the can down the road and deal with this all in ODF 1.3 or ODF 
2.0.

-Rob

Doug Mahugh <Doug.Mahugh@microsoft.com> wrote on 02/09/2009 02:31:59 PM:

> 
> I like this idea of having a better engineered extension mechanism 
> that allows the same capabilities as ODF 1.0, but structured in a 
> way that avoids the 
> Liabilities.  To merge threads, here are your comments from another 
> recent exchange on this topic, which I agree with:
> 
>  > Correct me if I'm wrong, but I don't recall anyone proposing to 
> add customXML in the sense of OOXML, to ODF.  I think customXML, and
> the specific semantics behind it,
>  > are reasonable, and if TC members want that functionality in ODF,
> then it should be supported in a first class way rather than via 
> generic mechanisms like bookmarks. 
>  > It would not be too hard to clone such a feature from what is 
> described in OOXML.
> 
> Regarding how long we'd be willing to wait for such functionality, I
> think we could clone the IS29500 approach pretty quickly.  That 
> doesn't address the issue of extensions in existing implementations 
> that may already use foreign elements, as others have alluded to, 
> but I think the addition of customXML functionality would be a good 
> thing to do.
> 
> - Doug
>