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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Re: ODF Conformance

So we have elements, attributes and attribute values.  My understanding is 
that the conformance clause talks about foreign elements and attributes. I 
don't think it says anything about prefixed attribute values,

I'd interpret this as saying:

1) If the schema defines an enumeration for the values of an attribute, 
then those and only those values are valid.  Any values outside of that 
enumeration, including prefixed ones would be invalid to the schema, and 
therefore not conformant.

2) If the schema assigns a single type like "string" but the text of the 
specification states that only a specific set of values are permitted, but 
ones which cannot be all listed into the schema, like country codes, or 
mime types, then any values outside of that list , including prefixed ones 
would be not conformant.

3) If the schema and specification allow any values then any values are 
OK, including namespace prefixed ones.  In fact, prefixed names would be 
preferred since they help avoid collisions.

So, I think the draw:engine case would be conformant.  The music:shape one 
would conform to the "extended" conformance class, but would not conform 
to the default conformance class.  That's how I read the proposal.

The intent is to get away from open-ended extension mechanisms and replace 
them with more targeted ones that better express the intent.  For example, 
we could define a shape extension mechanism, or a schema that generally 
specifies an alternative XML encoding  of the same content (MusicML versus 
SVG).  But without such a mechanism, an app has no idea whether the 
foreign element is a script that should be removed for security reasons, 
something that has accessibility consequences, something that must be 
translated when the document is translated, or whether it contains 
personal metadata that should be removed when anonymizing the document.

So I guess my questions are:

1) Is it worth having a better engineered extension mechanism that allows 
the same capabilities as ODF 1.0, but structured in a way that avoids the 
2) If so, how long are we willing to wait for it to be designed and 
specified?  I think it would probably take a 4-6 weeks.  We could likely 
get back to a single conformance level if we had a better designed 
extension mechanism.

I have nothing against extensions per-se.  I just want to ensure that they 
are done in a way which will scale with broader ODF adoption and not 
create problems that we'll never be able to solve.  This is one of those 
things we need to get right.


Thomas Zander <T.Zander@nokia.com> wrote on 02/09/2009 01:24:39 PM:

> [image removed] 
> Re: [office] Re: ODF Conformance
> Thomas Zander 
> to:
> office
> 02/09/2009 01:27 PM
> On Monday 9. February 2009 10:40:58 ext Michael Brauer - Sun Germany- 
ham02 - 
> Hamburg wrote:
> > Hi David,
> >
> > wouldn't it be an option to store the formatting properties in 
> > as application settings? This would clearly identify them as being
> > application specific. You may use the name of the style in the 
> > to identify the style to which them belong. And to identify a frame, 
> > 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 
> 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 
> both KOffice and Qt.
> At least, these implementations would in some cases no longer be able to 
> 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 
> 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 
>   <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 
> 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 
> 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 
> 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 
> types of data that are unique to KOffice. One of them is a musical 
> The editor saves its content using musicML. In a draw document this 
> that we get something like;
> <office:body>
>  <office:drawing>
>   <draw:page draw:name="" draw:id="page1" 
>    <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 
> to do that yet) so OOo can show the content just fine, but would loose 
> 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 

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