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


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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

Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?

--- On Mon, 6/23/08, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:

> From: robert_weir@us.ibm.com <robert_weir@us.ibm.com>
> Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Monday, June 23, 2008, 7:55 PM
> Sander Marechal <s.marechal@jejik.com> wrote on
> 06/23/2008 05:16:54 PM:
> > robert_weir@us.ibm.com wrote:
> > > Of course this could be a single document, with
> different sections 
> > > pertaining to each of: styles.xml, content.xml,
> etc.
> > 
> > Of course. My point was merely that there's more
> than one thing that
> > needs to be canonicalized.
> > 
> > This also leads to the question of: What about the
> related standards?
> > Are there c14n schemes for SVG? XForms? Zipfile?
> Should the OIIC TC make
> > those if the don't already exist, or will we
> simply use xml-c14n for
> > those until the W3C comes up with something better?
> > 
> You would need to do to the extent needed to achieve your
> goals, or at 
> least a worthwhile subset of them.  In terms of establish
> ODF equivalence, 
> I think Canonical XML, plus rules to deal with the
> arbitrariness of style 
> names and a handful of other factors gets to far.  But some
> things, like 
> vector graphics equivalence, may be impossible, at least in
> practical 
> terms

A possibility is to have signatures, equivalencies, etc, be defined on a per profile basis. In fact, that seems most natural. ODF as is might be akin to a core profile, but all other variations (eg, where SHOULD becomes MUST) could each lead to different definitions of equivalence.

Then we also have different families of equivalences as I think you suggest. For some types of diffs, we'd have one set of definitions, for another application (a differently useful diff), we'd have another set of defs.

So, (a) we have different things we are testing (ie, per profile basis). We also have different things to test for (diff type A vs diff type B).

One more note:

You had mentioned the use of canonical forms for signatures. In that case, we would need precision encoded somewhere (maybe outside ODF proper). Applications like this would likely require very strict rules.

OTOH, other applications of equivalencies could use a lower level of strictness. For example, the app could reduce the document to some canonical form and then cut off some branches or further reduce the form somehow.


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