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

On Monday 09 February 2009, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> The non-strict schemas as 
> it is further has the issue that is does not validate anything within 
> <*-properties> elements, not even the attributes that ODF defines itself.

This sounds like a technical issue more than a specification issue.
Surely there is a way to validate that style:wrap is not given the attribute "ooo:chicken curry",
while at the same allowing attributes from other namespaces. Basically we want
- if known attribute -> check that the value is valid
- if unknown attribute in known namespace -> error
- if unknown attribute in unknown namespace -> OK, app-specific extension.

> So, dis-allowing foreign attributes and elements in <*-properties> 
> elements is actually an attempt to improve validation and make make 
> things less complex.

But it's a bit too brutal an approach for solving the above technical problem, IMHO.

> Having that said: If it would turn out that application settings are not 
> sufficient to cover the past possibilities of foreign attributes and 
> elements in <*-properties>

Yes I don't think application settings are good way to extend styles, this sounds very messy.

Instead of
   <style:style style:name="fr1" style:family="graphic">
      <style:graphic-properties [...] koffice:frame-behavior-on-new-page="copy" [...] />
we would have to move that attribute to another XML file and do 
something strange like  
   <koffice:extension style:name="fr1">
     <style:graphic-properties koffice:frame-behavior-on-new-page="copy"/>

It can work technically, but it's very ugly in my opinion; slower loading
because the extensions need to be re-associated with their styles,
lack of modularity and clarity... Well, if that's the price for having a single
conformance level then I can accept it, but if it's just a workaround for
the lack of a proper validation tool, it's rather awkward.

> then I would have no objections to define an  
> extension mechanism there. But I would do so as feature of 
> <*-properties> elements, rather than as part of a "loose" conformance 
> definition.

Sound great to me :-)

I don't want "loose" conformance, I want extendable <*-properties>.

David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

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