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] PROPOSAL -- Name change for proposed TC


On Thu, Jun 19, 2008 at 5:43 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
>> I agree. But I see some value in alerting folks who fell for the ODF
>> Interop bees wax.
>
> Compliance testing can show up anomolies.
>
Anomolies? I thought they went extinct about the same time as the
do-do bird. :-)


> I moaned like hell at the xslt W3C rec.
> Full of 'implementation dependent' clauses.
>  We now have a good number of interoperable apps.
> It can be done.

Neat. Perseverence furthers. I often get the urge to just sue someone
rather than put up with the B.S. But I took a vow when I retired that
I would never again file a lawsuit if there wasn't blood on the floor,
so to speak. But I never could break my fascination with
toilet-training multinationals.Here I am.  :-)

>> There's stil the problem that when it comes to elements attributes
>> there's nothing left to test for conformance that isn't already
>> handled by validation against the schema after all foreign elements
>> and attributes are removed.
>
>
> Hence my earlier proposal to shift emphasis from compliance
> to recommendations to the main TC.
> This would address the para 1.5 issue.

Leaving only the violence to the rest of the element and attribute
specs done by the switch from the RFC 2119 definitions to the ISO/IEC
Guide definitions.

It would be a good start. FWIW, when we decided to stop banging our
heads against the ODF TC's interop stone wall and went public with the
interop bugs, I was working on a redraft of the conformance section to
put some teeth into it. I wasn't yet satisfied because I hadn't
figured out a way to deal with the  definitions switch issue and
needed some feedback on a technical issue or two, can't remember how
many. IIRC, it's an odt with three versions, the existing conformance
section, the revised version, and a diff plus a few short explanatory
footnotes. I couldn't tackle it with your expertise, but I did put a
lot of thought and research into it. In other words, it ain't bug
free. If my memory is right that it's an ODT or if it's in HTML, I
could stick it up on Google Docs and puit. Is that of interest?

>> But that brings to mind that I had a few more thoughts about which is
>> the definitive version of ODF. As I explained before, that depends on
>> legal context. But the new thought in that regard is that if one were
>> to ignore the law and approach the question purely from a practical
>> standpoint, the definitive version should be OASIS ODF 1.0. ODF was
>> developed using the RFC 2119 definitions. OASIS ODF 1.0 is the only
>> version of ODF not obliterated by the switch to ISO/IEC Guidelines
>> definitiions.The only way you can make any sense out of the standard
>> is to use the version that uses the RFC 2119 definitions. All other
>> versions never got the repair required to clean up the mess created by
>> the switch in the definition of "may."
>
> AFAICT may is not normative. I can fail a test against a 'may' clause
> but I can only issue a warning, not a failure.
> That keeps it simple.

You're right. In the RFC 2119 definition of "may," it's "MUST be
prepared to interoperate," so we're talking about application behavior
rather than normative But the way I read it as applied to the "may" in
the permission to write foreign elements and attributes, RFC 2119
"may" requires that an editor implementation be capable of writing to
the unextended version of the spec. That sounds testable if I stuck
the RFC 2119 definition of "may" or some such in the conformance
section and limited its applicability to the right parts of the
conformance section. I guess what I'm suggesting is that RFC 2119
"may" testability may vary depending on the particular context of the
"may" occcurrence. Am I on track here?

> If a long list of recommendations are published with Oasis name
> and the ODF TC ignore them, I think that could be dealt with.

Good.


>> I really appreciate your candor, Dave.
>
>
> I don't do bullshit Paul.

Noticed that a couple of years back. You were a breath of fresh air.

Best,

Paul

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


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