Re: [oiic-formation-discuss] Proposed Use case -- Interoperability in vertical and horizontal ODF markets

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

2008/6/28 marbux <marbux@gmail.com>:
> On Sat, Jun 28, 2008 at 4:11 AM, Dave Pawson <dave.pawson@gmail.com> wrote:
>> Round trip with an application that does not support ODF seems a dead end Paul.
>
> Disagree. That's what the foreign elements and attributes parts of the
> ODF spec were designed for.

Disagree Paul. They are for vendor X to add his fancy XYZ extension
to try and make you use his product instead of Y.
Nothing to do with the standard and compliance.






>
>> As above. If the other app doesn't support ODF that's a no go area as I see it.
>> If you want to propose that, IMHO that's a feature request?
>
> No. It's just part of the existing standard that needs fixed. And it's
> fairly high priority in my mind. It's the only part of ODF that
> standardizes the means of round-tripping between other formats.

Not IMHO. round tripping extensions is a good road to ruin.



> It's a mission critical item, particularly for ODF app integration in
> the enterprise market,

Back to ISO Paul. They are interested. I don't think this TC
formation is.



>>> There unquestionably is such a market requirement.
>>
>> +1.
>>
>>  This list is not the place to support it.
>
> You're telling me you have a user's manual for this list? :-)

No, just stating my opinion.



> IBM seems pretty set on not letting SC 34 deal with that in regard to
> ODF.

IBM doesn't run sc34, or jtc 1.


> But either way, the last time I looked at the relevant SC 34
> documents, the only thing on their roadmap is harmonizing OOXML with
> ODF and not even a timeline.

Watch this space.


>
> If you're going to do profile work, which is what is proposed without
> any detail, the notion of working from a constantly expanding superset
> of features back to a core profile seems imptactical to me. That would
> mean in effect that both ODF and OOXML remain big vendor-only formats.
> To me, the compatibility framework for round-tripping between formats
> has to be part of the core profile or the interop framework beneath
> the core-profile.

Not my view on it.


> Let me know if you haven't read it, but I see real problems with
> having a separate TC to do profile work if it's going to be wagged by
> the ODF TC dog. Profiles are standards and have to meet all the
> requirements for standards.

AFAIK this groups can't define a profile as yet. Standardizing them
seems like knitting fog.

 To me, this TC's profile work either waits
> until ODF is fixed or it has to break compatibility with ODF.

Or we knit them together and the user wins?


I look forward to embarassing the main TC with a long
list of unclear|untestable|no requirement feedback.

regards





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