Re: [office] Features for ODF 1.3/Next

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 08/08/2011 05:46:04 AM:

> Greetings!
> 
> Just a couple of questions to start the discussion of new features for 
> ODF 1.3/Next.
> 
> 1) To what extent would having a page model from XSL-FO enhance 
> interoperability? (This implies generally following XSL-FO as written, 
> not in compatible mode.)
> 

At first I thought that XSL:FO was dead at the W3C.  I haven't heard 
anything from them in quite a while.  But then I saw that they have 
rechartered with a new "XML Print and Page Layout WG.  Their charter 
includes an XLS:FO 2.0 revision as well as a test suite.

http://www.w3.org/XML/2010/10/xslfo-charter

So there are certainly possibilities there, especially if we had an 
liaison with that WG and could raise any additional requirements that ODF 
has.

As for its impact in interoperability...well... that depends entirely on 
the implementations.  It is very easy to end up one of two places:

1) A standard with loose conformance that everyone can claim to conform to

2) A standard with strict conformance that everyone ignores

Both of those cases give the user very little actual interoperability 
benefit.

The trick is to get something more like:

3) A standard with stricter conformance that everyone can converge on, 
over time.

That is the approach we've seen, for example, with CSS.

> I am thinking that using the XSL-FO page model would allow us to 
> describe the placement of objects in the terminology of XSL-FO.
> 
> Not that I care how an implementation accomplishes that placement, so 
> long as it serializes the result to XML that conforms to the ODF spec.
> 
> Thinking this would give us greater specificity without having to 
> re-invent a vocabulary in which to specify the placement of content on a 

> page.
> 

Yes.  But no doubt it would require vendors to change their layout code to 
accommodate this model.  I think we've seen that perfect translation 
between formats is not sufficient.   There are differences in the 
capabilities and layout models of the various applications.  If we specify 
the requirements in more detail, the first effect will be to illustrate 
non-conformance in more detail.  But unless vendors are willing to take 
that 2nd step, the user gets no interop benefit.

I'm not saying this is a bad idea.  I'm just saying that ideally, before 
we invest in that kind of work, it would nice if there were some vendor 
commitment to converge.


Another issues entirely is to what extent we need to (or should) do things 
to better support web-based ODF editors.  That appears to be where we're 
seeing investment today, to support web, tablet and mobile.  In some 
cases, a CSS layout model would be more appropriate that XSL:FO.  Is there 
any way to canonically map them?  Would that have value in a spec? Ditto 
for the underlying attributes.

> 2) To what extent would implementations be impacted if the draw 
> provisions of ODF 1.2 were re-written to use SVG 1.1?
>

We had some discussions about this on the list a while ago with Doug 
Schepers.  Two top level questions were:

1) Full SVG or a smaller profile like SVG Tiny?

2) How do we relate styles in the ODF document (the container) to styles 
in the SVG ?  SVG does define how it relates to CSS.  But we'd probably 
want something similar.  So if a graphic had embedded text that was 
defined to be using style "header 3" then it should be resolving that to 
use the "header 3" style definition from the ODF document.

 
> Just asking at this point, I need to review all the draw provisions and 
> see what that would take.
> 

Thanks for bringing these ideas up!

-Rob

> Would we want to deprecate current provisions with the promise to 
> terminate support in a following version?
> 
> Documents written using the older standard would still be valid, but 
> might not be supported by all software.
> 
> Hope everyone is 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 
>

S/MIME Cryptographic Signature