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] Value and danger of extensions


--- On Sun, 7/13/08, Peter Dolding <oiaohm@gmail.com> wrote:

> From: Peter Dolding <oiaohm@gmail.com>
> Subject: Re: [oiic-formation-discuss] Value and danger of extensions
> To: hozelda@yahoo.com
> Cc: oiic-formation-discuss@lists.oasis-open.org
> Date: Sunday, July 13, 2008, 9:11 AM
> People should not be complaining about having there not
> documented
> keys nuked either.   As the test of conformance we have no
> real valid
> way to test for them allowing for when they have to be
> deleted.
> Neither do applications like KOffice or OpenOffice so they
> are siding
> on the safe side delete anything they don't know.  If
> we delete
> harmless keys should do no bad.
> 
> The should maintain not documented keys and extensions is
> basically
> unworkable trash in the standard due to without
> documentation you
> don't know when they key or extensions should be
> deleted to keep
> constant layout across implementations.   This is leading
> to bad blood
> between implementers accusing each other of intentionally
> deleting the
> others keys.  They really have no option in the matter.  
> As well as
> being a breach of the TC charter.   We are to conform
> conformance to
> standard and foster compatibility between implementations. 
>   Its the
> breach of the second half we cannot confirm 100 percent
> compatibility
> between implementations with undocumented bits threw some
> means.
> 
> Its not our job to fix up these messes as it needs to be
> bounced back
> to standard body for fixing asp.
> 
> We need central reporting so we can test it.   We need
> central
> reporting so applications can know what keys are active
> keys what keys
> are inactive just data storage keys same with extensions.  
> As well as
> knowing when they should delete the keys or extensions
> because its
> going to cause a rendering error.
> 
> Or we need all extensions and added keys defined clearly by
> the
> standard as 100 percent inactive in document production.  
> Sorry there
> is no middle ground if we want to avoid fights between
> implementers.
> Its been the W3C down fall.  Fighting implementers does no
> one any
> good.
> 
> The line say application report to user about there
> existence is
> unworkable too since the conforming application ends up
> looking worse
> than the non conforming ones.

I generally agree with this, and it should be pointed out that coordination is something that benefits ALL COOPERATIVE PLAYERS. It's a plus as concerns aiding interop.

..After all, why *register*, why identify and mark off as special, the huge list of element names and attributes that compose virtually the entirety of the ODF spec? http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html

Perhaps we should have instead specified the intro xml tag, an ODF specific tag, and then made everything else a foreign element... which must be preserved ... or not.. do as you wish. Thank you for playing.

At less than 10 pages in total length, the dummies at OASIS could have saved themselves a lot of paper and us a lot of reading.



      


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