RE: [office] Re: ODF Conformance

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Very nice!

I particularly appreciate that your foreign attribute values use the QName
prefix technique (assuming you have an xmlns:koffice=... somewhere) to
differentiate your special values.  We should probably do more of that and
maybe define it as part of the foreign attribute value provision, at least
in a technical note on how to play nice at the extension level.

We see something similar in HTML work where the xhtml:rel attribute has a
number of fixed values but anyone can use a URI instead.  For RDFa, the URI
may enter via a CURIE, but that's not needed here.  So long as there is no
conflict with conformant values that look like QNames, everything should be
fine.  All we have to do is not define standard values that have ":" in
their expression.

Seems like nice work to me.

 - Dennis

-----Original Message-----
From: Thomas Zander [mailto:T.Zander@nokia.com] 
http://lists.oasis-open.org/archives/office/200902/msg00127.html
Sent: Monday, February 09, 2009 10:25
To: office@lists.oasis-open.org
Subject: Re: [office] Re: ODF Conformance

On Monday 9. February 2009 10:40:58 ext Michael Brauer - Sun Germany - ham02
- 
Hamburg wrote:
http://lists.oasis-open.org/archives/office/200902/msg00107.html
> Hi David,
>
> wouldn't it be an option to store the formatting properties in question
> as application settings? This would clearly identify them as being
> application specific. You may use the name of the style in the settings
> to identify the style to which them belong. And to identify a frame, you
> can use either its name, or its xml:id.

Looks a bit odd; and I'm not sure I have my head wrapped around it
completely.

I've spent most of today reading up on this issue and I'm a bit worried. I'm
a 
bit worried that we are trying to remove a core feature that I depend on in 
both KOffice and Qt.
At least, these implementations would in some cases no longer be able to
call 
themselves conforming. Which is at best odd.

My understanding is that KOffice can no longer write the koffice:nodeTypes
tag 
in its draw:path element. Which is essential to have for editing. Same for 
Inkscape (they just use the sodipodi namespace)
Is that indeed the case?

How about this one;
KOffice has various auto-shapes. One of them is the star.  We write this; 
  <draw:custom-shape draw:engine="koffice:star" draw:data="fooBar">

Qt has an odf-writer to export the text content to ODF. This is useful for 
clipboard usage, but certainly there are other usages.
I proposed to amend the fo:letter-spacing to fit usage by typesetting
apps[1], 
but this seems to not have gotten picked up. How does this affect ODF 
conformity?
And can we please get that feature in if Qt looses its conformity due to
this?

I'd like to point out that this change comes at a painful point in time; 
ODF1.2 has been feature frozen for ages (well over a year now, IIRC) and 
there are various features that should go in but can't. Many more people
just 
don't even suggest due to 1.2 still not being out.
I don't have a problem with a long stabilization time, but the counter 
argument given elsewhere that the features should go into ODF and people 
should not use namespaced options is not realistic.


A slightly more complex issue is with real extensions; KOffice has various 
types of data that are unique to KOffice. One of them is a musical editor. 
The editor saves its content using musicML. In a draw document this means 
that we get something like;
<office:body>
 <office:drawing>
  <draw:page draw:name="" draw:id="page1" draw:master-page-name="Default">
   <music:shape xmlns:music="http://www.koffice.org/music"; 
draw:style-name="gr1" draw:id="shape1" draw:layer="" svg:width="400pt" 
svg:height="300pt">
  []

The intention is to also add an svg version of the music shape (not sure how

to do that yet) so OOo can show the content just fine, but would loose the 
editing option on load/save.

1) http://lists.oasis-open.org/archives/office/200806/msg00021.html

-- 
Thomas Zander

---------------------------------------------------------------------
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