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


2008/6/19 marbux <marbux@gmail.com>:
> On Thu, Jun 19, 2008 at 1:31 AM, Dave Pawson <dave.pawson@gmail.com> wrote:

>> Telling Sun/IBM/FOSS guys how to do their job is
>> stupid and a waste of time.
>
> I agree. But I see some value in alerting folks who fell for the ODF
> Interop bees wax.

Compliance testing can show up anomolies.




> I'm going to stick around on this list and continue offering
> constructive proposals. History teaches that they'll get shot down.
> But I haven't given up on interop. I've been cussing interop
> breakpoints since the punched paper tape days and I'll probably still
> be cussing them on the day I die. The big vendors have no solution to
> the ODF interop problem. They *are* the ODF interop problem.

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.


>
>> Give them something to test compliance with a workable
>> standard (Conformance testing) and they might react positively
>> (sidestepping Pauls assertions).
>
> :-)
>
> 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.



>
> 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.




>> Interop responses would be a recommendation back to the main TC.
>> Conformance would be a test specification.
>> Profiles (the exchange profile is the most interesting one yet Paul) would
>> be a bonus.


> The barrier I see on what you propose is that the ODF TC would just
> ignore it unless the recommendation were accompanied by massive
> pressure on them to act on it. Maybe we could take the issue to the
> E.U. and see if they're willing to twist the necessary arms?

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



>
> I really appreciate your candor, Dave.


I don't do bullshit Paul.


regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


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