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] Deliverable: odf-diff?


On Sun, Jun 22, 2008 at 8:09 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
> 2008/6/22 marbux <marbux@gmail.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>


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