Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form

["Peter Dolding" <oiaohm@gmail.com>]

On Fri, Jul 11, 2008 at 1:30 PM, jose lorenzo <hozelda@yahoo.com> wrote:
> --- On Thu, 7/10/08, Peter Dolding <oiaohm@gmail.com> wrote:
>
>> From: Peter Dolding <oiaohm@gmail.com>
>> Subject: Re: [oiic-formation-discuss] Reason and example arguing for the use of an ODF (or XML) canonical form
>> To: "Bart Hanssens" <bart.hanssens@skynet.be>
>> Cc: "Stuart A. Yeates" <syeates@gmail.com>, oiic-formation-discuss@lists.oasis-open.org
>> Date: Thursday, July 10, 2008, 9:52 PM
>> On Thu, Jul 10, 2008 at 4:12 AM, Bart Hanssens
>> <bart.hanssens@skynet.be> wrote:
>>
>> > ODF 1.1, section 1.5:
>> >
>> > "There are no rules regarding the elements and
>> attributes that actually
>> > have to be supported by conforming applications,
>> except that
>> > applications should not use foreign elements and
>> attributes for features
>> > defined in the OpenDocument schema. See also appendix
>> D."
>> >
>> And I really hope section 1.5 gets deleted in ODF 1.2.
>>
>> It a wild west to compatibility.   Lets add something the
>> format just
>> different to spec enough to pass but enough that are
>> competition
>> cannot render it then completely not document it so we have
>> to be the
>> only used tool.
>>
>> For compatibility between implementations I don't see
>> were we can up
>> hold section 1.5 in it current state.   Either tc has to
>> run a master
>> list of foreign elements to check against and to give a
>> fair playing
>> field to everyone or we have to blanket report any foreign
>> element as
>> a possible compatibility issue..
>>
>
> Peter, I support and/or can relate to most of what I remember from your mailings. Do consider the email I just wrote: http://lists.oasis-open.org/archives/oiic-formation-discuss/200807/msg00118.html . The key part is the ability for us to shift focus as the market changes, but, as well, to address today where we can get the most bang for buck.
>
> In any case, there are many sections besides 1.5 that might be able to benefit from combing through for consistency and for precision/clarity [consider joining the "office-comment" mailing list if you haven't http://lists.oasis-open.org/archives/ ]. Also, something similar to the current 1.5 would be needed in order to promote and allow for the good aspects of extensibility (see top link).
>
> Rob also recently posted of work underway in ODF 1.2 (being undertaken by Patrick Durusau) to make the all-around language of ODF more precise. http://lists.oasis-open.org/archives/office-comment/200807/msg00091.html
>
> One thing I didn't mention is that there is plenty of room outside of OASIS for us/anyone to document and shame abusers and/or to reward those doing a good job. I intend to participate in these sorts of efforts to some degree. We can keep tabs on badly (or un-) documented foreign tags we come across as well as misbehaving implementations. Ultimately, we can even work on alternatives to ODF, but I don't see much of a need for that in the immediate future. The current standard is improving and being watched over. The potential market that can arise from good interop is very vast. This potential, the many eyeballs and watchdogs paying attention, and the competition from rival formats (each of which benefits from perceived interop) should keep ODF improving for our benefit into the foreseeable future.
>
The issue here is there two different ways to handle what foreign
keys.   One is Wild West Method.  Current 1.5.  No one completely
knows how many foreign keys are in use and who is using them.   This
in time leads to problems.  Someone create a foreign key that matches
someone else or worse redefines what a foreign key does but other
parities are using it without there knowledge.  In compatibility
problems.

Next is a non Wild West Method.  You can still create what ever
foreign keys you like.  Only limit needed added to 1.5 you must
register them with a central body with a complete description.
Anyone using foreign keys not register with required description is in
breach of standard.   Also who ever registers a key first it is theirs
unless the standard takes it.  Also being able to register that you
are using that foreign key so the creator of it knows.

Small change to ODF.  Large change to information, compatibility and
test ablity.   Information is key if like 10 different programs are
using the same foreign key for a feature that is missing ODF most
likely need that feature.  This is the other feature of register of
stuff like foreign keys if I look thew the list of all ready foreign
keys and the one I need is already there compatibility is
automatically gained.

Compared to current setup where there is no compatibility bar reversed
created unless a party decides to be nice and document.  Central body
wins every time.

Getting the non Wild West Method keys is not a long process.  Even a
mailing list could be the central body as long as its a agreed to be.
Rules about what parties could email for foreign keys would have to be
written for it.  Other than that no major overheads.  Under 8 hours
clearance should be more than possible.   There should be no
application needing quicker than that.

Everyone keeps on thinking of this as either or.   Ie either
flexibility or testability of standard.  It more than possible to have
both.  Flexibility alone equals problems and lack of information where
the standard can be improved for everyone's good.

Final thing how in the current system do you know if someone is using
foreign keys for information other than what they should.   Usage of
foreign keys is 100 percent not Audit able at moment.  Central body
makes it a Audit able thing.  Companies creating foreign keys for
stuff that exists would be pointing to either not wanting to follow
standard or section of standard document needing revising.

We are hear about testing compatibility.  Little alteration of
standard makes our job more 100 percent.

Peter Dolding