Re: [oiic-formation-discuss] "Strictly conforming" is not related to "interoperable"

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/14 jose lorenzo <hozelda@yahoo.com>:

>> > Contrast this to ODF, where specifically extensions
>> are defined as the addition of distinctly named element
>> nodes, and as long as these use (are qualified with) a
>> different namespace than those used in the standard, you
>> can still maintain "conformance".
>>
>>
>> Which is a facet of XML - not ODF or ooxml.
>
> No, this is a part of ODF (if I understood it correctly). ODF can choose to say that adding any foreign element breaks conformance *with ODF*. It would be wrong for ODF to say that adding foreign elements would break conformance with XML. I'm not sure why ODF would ever say that though since the conformance clause within the ODF std is about nothing more and nothing less than conformance with ODF itself (though ODF documents are a subset of XML documents, fwiw).


I would prefer to comment on what is present in ODF today, not what
they might do.
If you disagree with para 1.5, please send your comment to the main TC, it
is off topic for this group.






>> Some may not think this should be part of ODF, others do.
>
> ???
>
>> It is a fact and something that exists. Like adding
>> libraries to the C standard.
>> You may not like it, others will like it.

Not an issue for this group. Para 1.5 exists, and is unclear and is
not verifiable / testable.



>
> Adding something to the standard makes it standard. The point is about a vendor NOT adding their secret sauces to the standard.
>
>> embrace and extend? It is a possibility we have to live
>> with.
>
> It's beyond a mere likelihood, as I see it. In fact, even people that want to interoperate have a difficult time doing so (because of bugs and other flaws if nothing else) and, really, can effectively only interoperate by viewing each others' source code (at least in the worst case scenario).

Agreed. Perhaps that is one reason why this group needs to be formed.



> So to get back on track, without open source, it's very difficult to interoperate very well even when all parties want to. [Testing can help smooth things over ASSUMING people will WANT to interoperate. If you don't want to interoperate, it won't happen. It's much easier to be sloppy, go home early, not cross the t's, and make more money as other products fail to gain traction in the market place saturated with documents that do the interesting stuff in your secret "buggy" "sloppy" "go home early" language. What a solid standard and great tests can do with those that don't want to interoperate is to identify them so that their "certification" can be revoked.]


There is no ODF certification. Yet.
Hopefully any software derived from this TC work will be open sourced,
so anyone could test any implementation.
Without that the work of this group will be deeply flawed.

This point has not been added to the archive as yet.





>
> My point is all about the fact that at least one party does not want to interoperate, so I would say that we are talking about a lot more than a mere "possibility".

We have said repeatedly that this can happen, and is likely to happen,
and equally, that there is nothing we can do about
it without action that is too drastic to consider.



>
> All will not be in vain however if we can clearly root out implementations (apps) that are failing frequently and in many ways. In this case, the buy side of the market knows whom to avoid.

+1




>
> [Recap] My main concern are several:
> -- hopefully not let those that don't interoperate get a free and undeserved certificate/passing grade.
> -- perhaps a fairly good strong standard can be made to at least make it known if someone has violated it after the fact (and catching submarine feature implementations).
> -- finally, if possible, seek preventive measures by trying to have tests that will find as many violating cases as possible (and this means you want to avoid having vendors code to the tests since then the actual violations will be hidden).

We can't stop the last one Jose? That is one aspect of open standards.
All we can do is ensure bad testing is
made clear? If we have more than one test suite implementation and we
get disagreement of the results, we have
good reason to go further. We can help with this if test are grouped
into small groups so that an individual could
code up a group, they do not have to code up the entire test suite. To
me that is the best defence against
fraudulent testing.



>
> I think it will take constant effort to keep the tests up to date to provide the pressure on vendors to actually try and follow the standard instead of coding in the select special paths that pass the anticipated tests.


Another good point not yet addressed. Maintenance (and updates) of the
test suite! Who should do that?




> The standard can be bypassed submarine like through the payload of the ODF elements (eg, text:p). Thus, I think the standard would have to find tough wording so that at least in some tight profile, it could guarantee/expect/demand (for conformance) that the features of that profile could not be implemented except as defined by that profile explicitly.


Out of scope again Jose?



regards


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