Harmonization with IS 29500-3:2008 Marcup Compatibility and Extensibility

[marbux <marbux@gmail.com>]

[Replying on this list per Mary McRae's instructions]

Hi, Dennis,

On Sun, Mar 8, 2009 at 10:02 AM, Dennis E. Hamilton
<dennis.hamilton@acm.org> wrote:
> Paul,

> Your recommendation has inspired me to review the current document (also available at http://www.ecma-international.org/publications/standards/Ecma-376.htm).
>
> I think the IS 29500-3:2008 specification would do the job rather completely.  Relying on MCE is also in the spirit of ODF relying on existing standards where one is available.

Agreed.

> The fallback seems to be to leave Extended ODF Document, perhaps with tighter language around how non-understood elements and attributes are to be handled, until such time as MCE could be adopted.

Possible forward compatibility issues for ODF 1.2 if delayed?

> I don't see MCE availability as eliminating the Extended ODF Document conformance class.  On the contrary, any allowance of MCE elements and attributes might be limited to the Extended ODF Document conformance class when introduced.  I'm just guessing here.

I presume you mean only for app-specific extensions to Extended ODF?
There is precedent. The foreign element and attributes portions of the
conformance section in OASIS ODF 1.0 were intended as a similar
compatibility framework for extensions. The difference from later
versions was the flipping of the requirements keyword definitions from
RFC 2119 to ISO/IEC Directives Part 2 Annex H definitions at JTC 1,
specifically the change in the definition of "may" and "optional."

Under RFC 2119, "may" and "optional" are modal, bounded with two
mandatory interoperability requirements. The switch completely changed
the foreign element and attribute preservation requirements in the
conformance section.

The OASIS ODF 1.0 approach was incomplete and did not include
compatibility attributes, but the basic concept used in MCE was there.

> The provisions for inter-version compatibility are worth considering at a > fundamental (non-extension) conformance level.

I believe so. But I'd also caution that it is not an approach that
obviates all need for profiles or conformance classes to be created,
since lossiness is designed into the MCE approach.

> FURTHER ANALYSIS
>
> A. Non-Technical Considerations for Adopting IS 29500-3:2008
>
>   A.1 I am aware that there are those that will not find this specification acceptable under any conditions because of the feared prospect of a Microsoft intellectual-property dependency being submarined into the specification regardless of the various royalty-free arrangements that Microsoft has asserted, especially its Open Specification Promise.

I think it highly unlikely that Microsoft holds any relevant patents
or if so, whether they would stand up to re-examination on prior art
and lack of novelty grounds. The fundamental method was not original
in OOXML. There is prior art in OASIS ODF 1.0 and long before that,
Novell and Corel implemented a very similar framework in WordPerfect,,
commencing in WordPerfect 6.0, as a device to ensure non-lossy
round-tripping of documents among all versions of WordPerfect from 6.0
through 14 (so far).

Under the WordPerfect approach, the preprocessor steps through the
document, strips all <unknown> tags, then steps through the document
again, wrapping all unrecognized markup in <unknown> tags. (The
presence of compatibility attributes can be inferred from the app
behavior, although quite obviously there is no MustUnderstand
attribute.) The app then renders the content of markup so wrapped as
text, although any recognized markup within the marked span is
retained and processed.

That way, when the document is reopened in a later version that
recognizes the markup wrapped by the <unknown> tags, the
now-recognized markup is processed. So no markup lost when
round-tripping.

It's tried and true. I never encountered a misfire in that
compatibility framework, despite years running WordPerfect Universe (a
user-to-user support site). But perhaps more importantly, I think
Microsoft would have a huge problem proving that it was not aware of
that compatibility framework and at least the broad strokes of its
functionality.

WordPerfect was the program that MS Word unseated for the market lead
and both Word and WordPerfect extensively borrowed features from the
other during their feature war. And when Microsoft was creating and
extending its WordPerfect import filters, I'd place the odds that they
did not encounter and create filters to work around <unknown> tags at
about 0:0.

I also think a patent search could definitively resolve whether
Microsoft holds any patents reading on the relevant methods and
concepts. There are FOSS folk who are experts on such searches who
would probably be willing to undertake the task.

> B. Technical Considerations for Adopting IS 29500-3:2008
>
>   B.1 MCE seems to cover all of the bases as far as being able to control adjustment between versions of ODF as well as deal with use of extensions and even the selective reliance on extensions and add ins depending on what is understood and supported by an implementation.  It is an elaborate arrangement, and also raises some interesting questions about how and whether MCE should be optional or mandatory with respect to ODF conformance targets.  (This is a quasi-technical consideration, as all conformance-related conditions are.)

I see it as a framework that could not only handle extensions but also
bridge to some extent between implementations of less and more
featureful ODF profiles. E.g., the more featureful profiles could
directly specify the compatibility and alternate content markup to be
added for the document's processing by an implementation that supports
only a subset profile. If there are multiple supersetting profiles,
this might require multiple compatibility markup namespaces to target
implementations of each subset profile.

>   B.5 We need to deal with a typo in MCE section 10.1.3.2 where "ProcessAttributes" is used where "PreserveAttributes" is the only term possibly intended.

Prollly warrants a defect report to SC 34, so it could be fixed in an erratum.

I'd also like to see some clarification of circumstances where the
MustUnderstand attribute's use is warranted. This is the only MCE
compatibility attribute that has a mandatory requirement, the
must-abort-document-processing-if-you-don't-understand requirement.
There is room for potential abuse if left unclarified.

E.g., as written, a vendor could simply slap that attribute on all
extensions whether warranted or not to create interoperability
barriers for the competition, whose implementations would be
non-conformant if they ignored the attribute and processed the markup
anyway. I.e., what to do when an implementation does not *completely*
understand the markup but enough is known to make some sense of it
after consulting which vendor's namespace the questionable markup
resides in?

I don't have specific language to propose at the moment, but think
this an area that deserves study and clarification if ODF borrows MCE
from ISO/IEC:29500-3.

Best regards,

Paul E. Merrell, J.D. (Marbux)

--
Universal Interoperability Council
<http:www.universal-interop-council.org>



-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>