OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] W3C Compound Document WG

Hi Gary,

Gary Edwards wrote:
> Hi guys,
> Recently i contacted the W3C Compound Document TC, and Scott Hayman 
> (shayman@rim.com <mailto:shayman@rim.com>) wrote back to me requesting a 
> recent copy of  the OASIS Open Office file format specification to 
> review.  What is the OASIS policy on sharing the spec with non members?  
> Or members of other open standards groups we might consider coordinating 
> with?  

See below.

> Having read through some of their on line material, i'm wondering if it 
> would it be a good idea to coordinate with a group that could care less 
> about the OASIS work?  The total lack of awareness of the OASIS spec is 
> troublesome.  These guys were not born yesterday.  And as i page through 
> their on line disclosures, there is that wiff of not invented here 
> determination.  It also seems they blew off a letter from the OASIS DiTA 
> Group asking for a consideration about the use of the term "compound 
> document".
> Basically i wanted to know what was the purpose of the Compound Document 
> TC, and how their specification would be different from ours.   I was 
> looking to see what it was that the OASIS file format lacked that they 
> really felt was necessary to meet their mobile device oriented 
> approach.  The web site describes the "Compound Document" effort as one 
> where basic XML specifications for XForms, XHTML, SMiL, and SVG would be 
> mixed and combined into one document format.
> <CDF>" A Compound Document is the W3C term for a document that combines 
> multiple formats, such as XHTML <http://www.w3.org/MarkUp/>, SVG 
> <http://www.w3.org/Graphics/SVG/>, SMIL <http://www.w3.org/AudioVideo/> 
> and XForms <http://www.w3.org/XForms/>. The W3C Compound Document 
> Formats (CDF) Working Group will specify the behavior of some format 
> combinations, addressing the needs for an extensible and inter operable 
> Web .</>

The main differences of our TC and the CDF WG is that for the CDF WG

"It is not within scope to create a new document format for an specific
purpose, where the new format does not consist of a combination of
existing W3C formats."

while our TC exactly is about creating a new format. That we both have
in common is that we are combining existing standards, so a coordination
of both efforts might in fact be interesting.

> The membership is interesting.  It includes Microsoft, RIM, Nokia, 
> Adobe, SONY, SAP, Opera, and HP among others.  Definitely mobile device 
> oriented.
> Michael, do you recall why Nokia withdrew from the OASIS TC after the 
> fact to face meetings?  I thought it was because they were satisfied 
> with the XML flat file transformations, and saw no need to 
> participate.   I also thought that the most important issue for Nokia 
> was the ability to synchronize with desktop applications through the 
> OASIS file format.  Oh well.

I don't think one can say that Nokia "withdraw" from our TC. Actually,
we had one TC obersver from Nokia in our TC. He attended to our face to
face meeting in Menlo Park, but didn't have voting rights at any time.
He in fact is not listed as a TC observer any longer, but I don't know
since when this is the case. My assumption is that he disappeared from
the TC roaster when KAVI was introduced.

> Anyway, what does the group think about sending them the specification 
> for review and consideration?  And is that legit?

Regarding the availability of our specification: In fact, currently only
specifications that have been approved by the TC are available
publically. The interim working drafts that the specification editors
currently upload nearly every week are only visible to the TC members
(voting members and observers). This has no specific reasons, except
that our TC never discussed whether the interim drafts should be
available publically, and that it has never been requested by by someone
who is not at least a TC observer to have access to the specification.
However, we are usually creating a lot of interim drafts when we are
close to committee drafts votings, and I'm not sure whether it is really
reasonable to make all these drafts public, because it becomes very
difficult to process feedback if it might be based on too many versions
of a document. I think we should discuss that in our con call today.

If someone requests access to an interim version of the specification,
when I think we should make that version available publically rather
than distributing it manually.

> ~ge~


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