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

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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


Subject: RE: [opendocument-users] RE: office-comment text:id vs xml:id (ODF 1.2CD01)



> 1. I have one strong reservation.
>
> 3. I am beginning to think, as a result of further study today, that we
> should prepare ODF for introduction of MCE Conformance (from IS
> 29500-3:2008).

+1

>    3.2 I do think we can word the treatment of elements and attributes
> identified in not-understood foreign namespaces, and the rules for
> office:preserve-content, such that (1) one could correctly introduce
> use of MCE as a foreign namespace in such a way that its future support
> in the specification would be consistent and (2) it would have natural
> use as a document extension of extended ODF documents for now, and (3)
> it could be introduced as an optional feature of either extended or
> conformant documents in the future without any disruption whatsoever.
> [I love it when we can make something like that work.]

+1

>    3.3 I think we should immediately adopt the principles of MCE around
> not subsuming (or reusing) an earlier namespace unless all
> specifications of previously known namespace names are unchanged.  That
> is, if we insist on a breaking change, the changed element or attribute
> must reside in a new namespace.

+0.5   I don't think MCE does forbid the known namespace being added to.
It is more about how to treat markup in unknown namespaces. In general, a
breaking change is better handled incremementally rather than a clean
break: think on-ramps and off-ramps. So the old element allows both old
and new values, with generating data of the old values deprecated
(obsolescent, and being removed in some future version) and a clear
mapping from the old to the new.  This corresponds to how applications
will actually work (i.e. accept any 1.n.)

In other words, the policy is not backwards compatability in the sense
that any 1.m<n document is acceptable as a 1.n document, but that only a
1.n-1 document needs to be acceptable as a 1.n document.

Cheers
Rick


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