Re: [oiic-formation-discuss] My perspective. Extensions

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

2008/6/30 Peter Dolding <oiaohm@gmail.com>:
> On Mon, Jun 30, 2008 at 5:20 PM, Dave Pawson <dave.pawson@gmail.com> wrote:
>> 2008/6/29 Thomas Zander <zander@kde.org>:

>> I'd prefer a simple definition.
>> A known feature is define in the spec.
>> An unknown one is not defined in the spec. Other name, an extension.
>>
>> Lets say vendor A doesn't implement/support  SVG?
>> Is that a known feature or unknown, to that vendor?
>> I'd define that as unimplemented. A test should reveal that.
>>
>
> Misses a critical one.  Where do you draw the line.
>
> How long before we have a undocumented mess of private application
> additions.  As a testing conformance undocumented messes cannot be
> tolerated.

Not misses it Peter, just acknowledges it as fact. That's one way that Thomas
and other vendors add good stuff (as well as bad) to the spec. If they offer
it up to Oasis it can be drawn in to the spec.

All we can do is recognise it as an extension.


>
> Min all extensions must be fully documented and put forward for
> approval into the standard.  At this point as a TC asking for
> tolerance to be considered will be taken seriously.  Reason you have
> done everything you can to get that feature in the standard and to
> work with others.   Of course the TC has the right to say different
> way has been approved to do the same thing and you need to update your
> application.

+1

>
> Now we have the reverse where its undocumented and never has been put
> forward as a extension to the standard or put forward as a extension
> but has black boxes we cannot give any tolerance.

Don't process it, but don't screw it up for others? That's what the spec says...
for extensions in known areas.

Thomas makes the point about metadata though. Lousy unclear definition,
no requirement to write this back to disk for others to process?


>
> Its a simple line solid and strict.  Anything else will screw up the
> standard.   It has worked well for other standards.
>
> Anything allowing undocumented blocks in the standard also gets on the
> wrong side of a TC.   We want clear and above board documentation so
> we can check that is working.  Not black boxes.

I disagree with that position. Allowing extension has worked with most
of the W3C standards.
Keep your extensions in a.n.other namespace so we can knowingly ignore them.
It's healthier if they are constrained clearly though.

An easy one is for all KOffice extensions to use  a consistent prefix
ko:extensionElement etc.
ditto all the others. Then you know who to ask about that sexy new extension
you fancied.


regards


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