Re: [oiic-formation-discuss] Canonicalizations galore

[jose lorenzo <hozelda@yahoo.com>]

--- On Tue, 6/24/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] Canonicalizations galore
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Tuesday, June 24, 2008, 1:43 PM
> jose lorenzo <hozelda@yahoo.com> wrote on 06/24/2008
> 12:31:18 PM:
> 
> > 
> > Since canonicalization of XML is not something unique
> to ODF, it 
> > will exist regardless. Two questions might be,
> "to what extent will 
...
> I must say that this is all very interesting, and I can see
> the general 
> use for a definition of canonicalized ODF.  But I'm
> losing track of why 
> this is relevant to profiles or to the goals of the
> proposed TC in 
> general.  Is this really needed for us to achieve our
> goals? 

I too think it's very interesting.

The market starts growing. The wheel gets reinvented. Small differences end up creating interoperability problems for the many tools that would like to interact and get on the same wavelength.

In a nutshell, I see the OIIC TC's involvement as an ongoing process. Canonical mappings is one (interesting) area that is likely to lead to conflicts and could benefit from a central authority to lay down the precise rules.

Eg1: the TC can help to develop and standardize a few (to become) well-known parameterized canonicalization algorithms. The TC can get started right away (eg, Sanders and others mentioned some useful items that could be folded over (factor out) of diff calculations). Likely there would be at least one canonical mapping that many would immediately find useful for handling ODF (eg, testers have their needs). Thus, an actual such mapping (or two or three) might be specified as a deliverable. Additionally, the TC would be tasked with coming up with more mappings based on demand, and/or making other necessary changes to ODF (in conjunction with the main TC...) or to test suites, etc.

So over time, a growing body of needs/ use cases would become accepted. The market could benefit from someone going through and defining the exact details so tools could interoperate. This TC could step in as the authoritative group for ODF related issues (mappings or whatever).

As for profiles..

Profiles, too, may be a variable in these algorithms. A limited device/profile may cue in a bunch of simplifications. In an extreme case, there may be a case where only circles exist and no ovals or only triangles and not rectangles or tables/spreadsheets are overly simplified, both in terms of the model and the potential views. Thus a profile might limit the ODF components in play (perhaps also defining the precise semantics). A companion canonical mapping different from those of other profiles would then be needed.

On parameterization..

Parameterization would be very useful since many times the exact item one wants to be a diff will vary slightly from use case to use case to user preferences, etc. Eg, in the rectangle drawing example, a parameter might be: (a) pixel perfect or not or using some well-defined method of calculation (and these details might depend on whether we have a mobile profile or some other profile); (b) the coordinates attributes are dependent on localization issues or not or in some specific well-defined way; (c) if the rectangle is seen as a 2d or 3d figure, perhaps bringing into play more items; etc. Maybe the coordinate system used to specify the coord values (eg, polar vs cartesian) will be an important diff or not.... so the point here is that there are many possibly ways to want a diff to work yet much of the variation might be able to be parameterized away compactly.

Concluding..

In short, the TC would help standardize, on an ongoing basis, individual or classes (ie, parameterized) of canonical mappings that would be in common use (ie, address well-defined use cases). Without a central std, the tiniest of problematic differences in tool interfaces will arise to thwart interoperability.

The scope would be limited to ODF related issues, of course, but this might eventually mean dealing with inter-protocol/inter-format issues.

Anyway, I have suggested a few specifics (informative background setting, TC deliverables, TC scope), but there are a lot of missing details and more possibilities or variations in how the TC might be involved.

What language might be suitable for the charter? Help?