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

 


Help: OASIS Mailing Lists Help | MarkMail Help

odf-adoption message

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


Subject: Re: [odf-adoption] ODF and UOF



On 2009-07-07, at 13:58 , robert_weir@us.ibm.com wrote:

> Thanks for the update.
>
> If they move UOF into OASIS or ISO, then we have ways of  
> coordinating with
> then at a technical level.  Otherwise, it will end up being done in  
> China
> by those companies that have staff there.

That was my impression, too. It struck me that by keeping it in China  
development and implementation by international companies would be  
limited. (I repeat what you write.)
>
> As for harmonization, I think the approach to harmonize  
> requirements, but
> not necessarily try to merge things at the markup level.  The goal  
> of ODF
> is to be suitable for office productivity applications anywhere in the
> world, not just the West.  So if we're missing something, we should  
> add
> that feature to ODF.

Is it about features or basic structural layout?

>  But in doing so we'll do it in a way that harmonizes
> with the rest of ODF.  Otherwise we'd end up with some Frankenstein
> monster format, with pieces from different bodies stapled together.

Right.
>
> But I think we're heading on the right path here.  For example, Peter
> Junge has contributed a proposal to the ODF TC regarding diagonal  
> table
> headers, a key requirement for Chinese documents.

Right. Would this be difficult to implement in an application  
supporting ODF? Ie, to generate the right content? And would this then  
also affect output and thus compatibility with, for instance, MSFT  
Office 2003 and beyond? In short, if we are looking for a solution to  
compatibility not only with UOF but more generally with ideographic  
scripts, then what's the simplest path, and would it be in addition to  
adding elements (but not monstrous ones) to ODF?

>  Maybe we make better
> Asian document support a theme of ODF-Next?

Let's. The issue is of some urgency, in that the government *will*  
insist upon the mandate, I have been told. OOo *can* and *does*  
support and even implement UOF but again, I don't know with what  
fidelity or conformance. Anyway, improvement is wanted.

And having as a general goal, then, Asian script document support as  
the theme for ODF-next gives us the necessary claim that should  
satisfy would-be enterprises (public, private) required to use UOF.

I wonder if having discussions and work on the ODF Toolkit Union makes  
sense?


>
> -Rob

-louis
>
> Louis.Suarez-Potts@Sun.COM wrote on 07/07/2009 10:44:53 AM:
>
>>
>> I was just in China and discussed ODF and UOF harmonization as well  
>> as
>> improved support for and implementation of UOF by OOo. At present,  
>> OOo
>> supports it and since 3.x can save in UOF but evidently only
>> imperfectly. The idea would be to improve this, in particular for
>> ideographical scripts.
>> UOF, of course, is the government-mandated format for its documents.
>>
>> So, this raises the set of questions below:
>>
>> * Status of UOF as a specification?
>>
>>   From conversations with the RedOffice team and with Peter in
>> particular, UOF seems to be charging ahead and reaching 2.0. However,
>> there seems to be little movement to relocate it to Oasis or to drive
>> it to ISO standardization. Neither would directly enhance
>> interoperability with ODF but either would likely raise the
>> consciousness of the format among stakeholders.
>>
>> * Status of ODF UOF harmonization?
>>
>>   And, how desirable is this? At our meetings, we discussed the
>> possibility of effectively merging the specifications, so that the
>> elements missing in ODF but present in UOF and vice versa would be
>> completed. Problem is, the basic layout of the page differs from
>> format to format, so a simple cut and paste effort is not likely. My
>> guess is that a native-code (C++) conversion might be required for  
>> this.
>>
>> This effort might also have some other consequences, as it seems as  
>> if
>> UOF is closer in its formatting logic to OOXML than ODF is. Thus,
>> compatibility with OOXML might be--I have not checked this--improved
>> by this work, providing it's reasonable.
>>
>> * Logistics of any related work?
>>
>>   That is, do we (stakeholders) have a good sense of how much work
>> would be required to produce results that satisfy demanding  
>> enterprise
>> users of UOF so that they are happy (or reasonable facsimile thereof)
>> when they use OOo or its derivatives?
>>
>> Thanks
>> louis
>>
>>
>>
>>
>>
>>
>>
>>
>> http://www.robweir.com/blog/labels/UOF.html
>>
>> ---------------------------------------------------------------------
>> 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
>



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