Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, ANDSUGGESTIONS No. 1

[Sander Marechal <sander.marechal@tribal-im.com>]

marbux wrote:
> But my proposals deal only with CDRF, the interop framework.
> <http://www.w3.org/TR/CDR/>.  CDRF is *not* a format standard
> implemented by other applications that ODF implementations could
> interoperate with. It is a not a markup language or set of formats. It
> is an *interoperability framework.* CDRF is an *application and
> format-neutral* specification that specifes:
> 
> [i]  requirements for development of compatible profiles of compound
> document formats working from a core profile to progressively
> super-setting profiles;
> 
> [ii] requirements for creating compound document formats (unnecessary
> for ODF because ODF already *is* a set of compound document formats);
> and
> 
> [iii] a set of processing instructions and conformance requirements
> for round-trip interoperable processing of profiled content, including
> requirements for round-tripping between implementations of the less
> and more featureful profiles.
  >
> The only barriers to achieving round-trip interop between
> implementations of less and more featureful ODF profiles using the
> CDRF specification are: [i] the work necessary to devevop the ODF
> profiles -- that everyone seems to agree are needed -- in conformance
> with the  CDRF requirements for profile development; and [ii] the
> minimal work necessary for developers to implement the processing
> instructions specified by CDRF for the processing of profiled content
> in conformance with the CDRF spec. Because CDRF was designed to be
> application and format-neutral, there are no application or format
> dependencies. CDRF is specifically designed to work  with any
> combination of plain text-based formats.

I just read the entire CDRF spec you linked to, but I couldn't find as
much as you seem to get from the spec. What I gather from it:

* Referencing child objects is done by whatever way the parent format
specifies natively.
* An optional "profile" attribute can be used along side the content type
* A way to access the child DOM from the parent DOM an vice-versa
(including events)
* Subset profiles can't ann features, only remove features from the base
profile

Everything else you described in your (rather long) post is
application-specific implementation of CDRF. Things that could be done.
Not things that are defined in the spec.

I have to agree with Rob Weir here. CDRF doesn't have a place in the
charter. Have the TC figure out what the best way is to build profiles
for ODF. Maybe that CDRF. Maybe it's something else. Maybe it's CDRF
combined with something else (from reading the spec, it doesn't seem too
hard to combine the CDRF recommendations in a more detailed profiling
spec). It's very much dependent on what profiles need to be created and
what the use for these profiles is.

Perhaps you should recommend CDRF to the TC once the TC has started and
is working on profiles.