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] Preservation question


Hi Patrick,

This is exactly the point. Preservation requirements could in my opinion
only be specified by specifying allowable functions on ODF documents.
Something in terms of:
Let V be the set of all valid ODF documents.
I.e. document instances conforming to the schema. This set is defined by
the ODF specification.
Furthermore, let F be the set of all operations f: V->V. These are
possible editing features implemented by ODF applications.

If we want to specify what a conforming application may or may not do
with an ODF file, we need to write a specification that defines a subset
of F, FP containing all permissible operations. Any feature g in a
conforming application must then be expressible by a combination of
operations in FP such that g(v)=f1.f2...fn(v), where f1...fn in FP and v
in V. Thus, the validity of an ODF instance v1 can no longer be
validated through schema validation but must also take into account the
question whether a sequence of operations exists in FP for which
f1.f2...fn(v0)=v1 holds, where v0 is the previous revision of v1 and v0,
v1 in V.

As I understand our charta, our mission in this TC is to specify V. We
can give guidelines for application behavior but we cannot mandate it.

It may or may not be possible to write a specification for F0. And I
think anyone who wants to do this is free to do so. I just don't think
that this TC is the place to do this.

/Lars


Patrick Durusau wrote:
> The problem with specifying preservation in general is that it means you 
> have to define what that means for processing models, which isn't 
> something that ODF has ever done. It defines a document format, not how 
> you process it.
> 
> Noting that defining an environment in which an editor exists is 
> fundamentally different from that of a regular XML processor. A schema 
> or DTD can define xml:ids and it is straightforward to give the rules 
> for xml parser because it is never going to change or edit the text. 
> That is not the case with an editor. The reason why editors exist is to 
> change the text and to do so, they have to have a certain amount of 
> flexibility.

-- 
Sun Microsystems                Lars Oppermann <lars.oppermann@sun.com>
Nagelsweg 55                    Software Engineer
20097 Hamburg, Germany          Phone: +49 40 23646 959
http://www.sun.com/             Fax:   +49 40 23646 550
-----------------------------------------------------------------------
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten, Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering



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