[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Deliverable: odf-diff?
On Sun, Jun 22, 2008 at 8:09 AM, Dave Pawson <firstname.lastname@example.org> wrote: > 2008/6/22 marbux <email@example.com>: > >> At least with elements attributes, just about every conformance is >> already tested by validation against the schema after all foreign >> elements are removed. > > Not quite Paul. 2.4.1 > An attribute value that 'should be' a QNAME as per xml 1.0 > A should be, not verifiable by a validation against the spec. Not sure I understand here. "Should" doesn't create a normative requirement. It's only a recommendation and a document can be conformant without the implementation/document abiding by the recommendation. So the way I understand it, one could test whether "should" has been done but the test result doesn't relate to conformance. Lapsing into an area where I have more expertise, there's a WTO Appellate Body ruling on the Agreement on Technical Barriers to Trade holding that a technical standard must: [i] fully specify all characteristics [ii] only in mandatory "must" and "must" terms [iii] of an identifiable product or group of products. That doesn't mean you can't have any options at all, the way I understand it, but you have to be really careful about how you word them and "should" really belongs only in in a best practices guide rather than in a standard. E.g., I think one might permissibly say that "you may optionally choose between doing X to achieve result Z or doing Y to achieve result Z, but either way you have to read and write Z. In other words, I don't see much legal room for options in a document format standard outside the realm of specifying application behavior. And "should" isn't normative. Am I misunderstanding what you meant? >> That and the fact that there are no interop conformance requirements >> are why I raised the issue of timing in what you want. I.e., do we >> build tools for the existing spec or the repaired version. I'm not >> against what you want but I don't see the need for it before the spec >> is fixed unless the goal is application-level interop hacks rather >> than a tool based on conformance requirements. > > That's a catch 22 as I see it. > > We can't fix the spec unless the TC is scoped to do it. > That's what the main TC is scoped to do (work the spec) > hence until we have a list of : > This is untestable please fix it, > then go round the loop again > Then we can test it. > > That seems the most reasonable way to get what we both (all?) want. Dave, I think it incredibly useful information to have and to deliver to the ODF TC whether the testing work gets done on this TC or the ODF TC. I agree it's that TC that has to do the fixing unless we reinvent ODF here. At the same time, we already have enough information to say that: [i] the spec is so badly broken that no different ODF apps can interoperate and less and more featureful ODF apps can't interoperate; [ii] minimally, to address both those issues, we need a work plan that is feasible both for the standard writers and the developers to implement in bite size pieces; and [ii] it requires a workplan like CDRF plus a compatibility framework to work outward from a core profile to supersetting profiles in 1 or more branches of profiles that are compatible at each layer of the profiles, e.g., keeping the business process and pixel perfect branches in synch with the pixel perfect profiles supersetting their corresponding business process profiles. . I guess what I'm getting at here is that we need to send the ODF TC more than test results and "please fix it" requests. Whichever TC is going to do the profile work, that TC has to have a work plan that is pretty comprehensive for the repair work and goes way beyond just writing an interoperable spec for the most featureful apps. We've also must get the less and more featureful apps to interoperate if we're going to break the Microsoft Office-Sun OpenOffice.org-IBM Lotus Symphony oligopoly and level the competitive playing field. The reason *none* of the big vendors have a solution to the interop problem is because they *are* the interop problem. The interop barriers are not technical, even between less and more featureful apps. Best regards, Paul -- Universal Interoperability Council <http:www.universal-interop-council.org>