CDRF-like wrapper to handle elements via profile whitelists

[jose lorenzo <hozelda@yahoo.com>]

From http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00353.html

--- On Mon, 6/16/08, marbux <marbux@gmail.com> wrote:

> From: marbux <marbux@gmail.com>
> Subject: Re: [oiic-formation-discuss] MARBUX POINT OF ORDER, OBJECTION, AND SUGGESTIONS No. 1
> To: oiic-formation-discuss@lists.oasis-open.org
> Date: Monday, June 16, 2008, 1:16 PM
> On Mon, Jun 16, 2008 at 3:11 AM, Sander Marechal
> <sander.marechal@tribal-im.com> wrote:
> 
> > To explain myself a little bit better: I believe that
> this committee's work
> > is focussed on interoperability in the ODF world,
> building test suites and
> > tools that help ODF applications become compliant with
> the standard and
> > helping ODF applications interoperate with each other.
> I don't think that
> > the committee's work includes the interoperability
> of ODF with other
> > standards such as OOXML, CDF, UDF or even PDF and HTML
> for that matter.

...

> CDRF not only enables this kind of round-trip processing
> between less
> and more featureful implementations; it requires it. Those
> are the
> kinds of interop doors opened by designating CDRF as the
> interop
> framework to be used for the ODF profile work. E.g., one
> provision
> from the CDRF conformance section reads:  "A
> conformant user agent of
> a superset profile specification must process subset
> profile content
> *as if it were* the superset profile content."
> 
> I.e., an implementation of an ODF desktop word  processor
> profile
> (more featureful) that opens a document generated by an
> implementation
> of a subset ODF web app editor profile (less featureful)
> would process
> the document as though the latter were the superset. The
> document can
> then be edited in the more featureful app and sent back to
> the less
> featureful app in a vocabulary the less featureful app can
> understand
> and process correctly.

...

Completely like this approach for handling profile levels.

> ... That takes an
> interop
> framework, and why should we develop our own when W3C has
> years into
> inventing that wheel for us? Just to create
> incompatibilities with the
> W3C wheel? What other justification is there?

If the entirety of that effort is compatible with "our" goals, I see no reason to reject it.

I like the explanations you gave above for handling profiles. It's a concept I think we want and the details may have already been hashed out. We could use a framework with properties as you described as far as handling profile levels is concerned.

> ... There is thus a need for a
> compatibility
> framework as well, markup and processing instructions for
> the
> processing of unrecognized metadata. I will save that
> discussion for
> another post.

Let me offer a suggestion that ties foreign elements with profiles.

We can have the outside wrapper (eg, something that has the CDRF feature you described) require a *whitelist of pre-specified profiles* much as namespace whitelists are included in XML. This mechanism might be how we handle "foreign" elements alongside ODF profiles. The foreign elements would be nothing but elements defined as part of one or more custom profiles.

At the outermost level (just inside it), the document specifies the profiles it handles. It might specify ODF/A, ODF/A.2+, and "my-fsf-subset".

[profile name="ODF/A" profile-def="http://...."/]
[profile name="ODF/A.2+" profile-def="http://...."/]
[profile name="my-fsf-subset" profile-def="http://...."/]

A profile-def would link to something much like a DTD, some other standard schema, maybe a Schematron definition (?), etc.

Through this method, all element tags would effectively be first class objects, whether standardized and part of a standard ODF profile or simply specified/named as part of a custom profile.

This outside shell would itself have capabilities. Eg, one might require the ODF consumers to only understand how to deal with DTD v. x. This might form a lower bound so that you can at least perform basic validation or know if to complain about foreign elements. [This also means that perhaps all profiles should require a DTD.]

We might also specify rules that the set of allowable profiles could not be changed without explicitly warning users. This is the default behavior. profile-list="fixed"

The outside shell can also specify "complaint" levels.

In the above example, my-fsf-subset would be defined at the url specified. It would essentially say that I could include "fsf:license-title" and "fsf:license-body" as elements. Along for the ride would be a semantic bundle attached to these two elements, as defined within say a DTD. This custom DTD might "point" to the FSF's DTD element descriptions for these two elements only.

[I don't know if a direct way exist to do this pointing to a subset of a (eg) DTD. ODF incorporates pieces of other standards but redefines inline the necessary Relax-NG schemas. For a standard, it's important to have control, but for custom tags, you may want a pointing mechanism to allow, eg, the FSF to manage "fsf:license-title" and "fsf:license-body" on your behalf.]

Ditto for the ODF/A.1 and ODF/A.3+. The latter means version 3 or later while the former refers to version 1 only. We may want to codify a shortcut (like how .so versioned libs are handled in Linux.. maybe something using XPath) or else simply have the ODF/A.1 link describe version 1 all the time and have ODF/A.3+ be kept updated over time to include all versions 3 or above.

The superficial difference between these profiles (and included elements) is that one group is defined by OASIS while the other is custom.

One thing to study is how to keep the XML DTDs schemas etc in sync (consistent) with the profiles.

I like this idea much more than allowing any foreign element to coexist (unless you fail to omit the profile or specify "ANY"?).

Does CDRF behave similarly to the above?