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] Conformance Clause proposal, Version 8


The strict versus loose conformance dichotomy is most typical used in 
cases where "loose" is the legacy format, including warts, and "strict" is 
a cleaner version that the committee defines.  XHTML and OOXML use it in 
that sense.  It isn't a statement about extensibility or the allowance or 
denial of extensions.  For example, both loose and strict OOXML allow 
extensions, while neither strict nor loose XHTML allow extensions.

But where you talk about extending an XML vocabulary with other name 
spaces, the practice is to call the vocabulary extended in that way the 
"host language".  By using that convention we would be following 
established practice, regardless of whether that practice is "geeky" or 
not.

In any case my preference remains to stick with a single conformance 
class, not permitting namespace extensions.  If we want to create a host 
language profile at some point, then that would also be fine with me, but 
we would need to address the kinds of issues I raised in my previous note 
regarding identification of executable code, personal content in 
documents, document assembly, referential integrity, etc.

Of course, by now everyone knows what Dennis and I think on the matter. 
Our votes will obviously cancel each other out.  So what really matters is 
what others on the TC think of the proposal.  I'll look forward to reading 
them on this list and in our call on Monday.

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/05/2009 
03:14:28 PM:
> 
> Michael,
> 
> I will examine the revision with great interest.  Thanks for your 
struggling
> with this.
> 
> 1. I favor the two-tiered approach, as you know.
> 
> 2. I am assuming that the only schema will now be what has been called 
the
> strict schema in the past.  That is an useful simplification.
> 
> 3. I don't like the names very much, but that may be just me.
> 
>   3.1 For one thing, I have become fond of "strict conformance" and
> "strictly-conformant."  I find that a powerful designation and I think 
it
> aligns with the strong goals of those communities that establish
> requirements for use of strictly-conformant ODF Documents in interchange 
and
> for public and civil purposes.  It seems useful in branding, badging, 
and
> for other purposes where documents are expected to be squeeky clean. 
> 
>   3.2 For the other, the term is simply too geeky and I don't think it 
helps
> maintain a common understanding of what it is about.  I guess it means 
that
> ODF is the host language for a customized version with limited 
extensions
> (foreign elements being a circumscribed way of doing it, especially if 
the
> underlying strictly-conformant ODF document is meant to be useful).  Is 
that
> the sense you give it? 
> 
> 4. I am not objecting to qualifying the term if it is as easy to convey 
as
> strict conformance is and we are clear about the correspondence with
> "conformant" in previous specifications.  [In thinking out loud, below, 
I
> came up with "conformable" for the document, in contrast with the
> strictly-conformant document, but producers would still be conforming 
and
> strictly conforming, I think.]
> 
> 5. Maybe we can kick this around for a few days in search of a better 
term.
> If strict conformance is as appealing to others as I find it, maybe we 
just
> use plain conformance in the sense it has for ODF 1.1 for now, with 
leaving
> the search for a better term open. 
> 
>  - Dennis
> 
>  - - - - - - - - - - -
> 
> More thinking out loud -
> 
> Terms I rejected when thinking about this:
> 
>  - loose conformance (has the right tone, but can apply as easily to a
> strictly-conforming consumer and producer)
>  - weak conformance (same problem as above)
>  - limited conformance (ditto)
>  - modified conformance (again)
>  - altered conformance (?)
>  - custom conformance (sounds too much like a feature)
>  - extended conformance (likewise)
> 
> If the words conformant and conformance are not used, or not used alone, 
so
> there is no contraction that creates confusion with (strict) conformance 
and
> (strictly) conformant, that might be more promising.
> 
>  - dialect
>  - variant
> 
> [I am tempted to list "deviant," but we should save discussion about
> deviations to apply to all deviations around fully-implemented
> strictly-conformant documents consumed and produced by a processor.]
> 
> If there was a term that reflected how a strictly-conformant document is
> obtained by reducing out the foreign matter, that would help too.  I 
thought
> of "reduced conformance" but that is off base, even though it might be 
the
> right kind of tone.
> 
> Oh, how about "conformable?"
> 
> 
> 
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> Sent: Thursday, February 05, 2009 05:24
> To: OpenDocument Mailing List
> Subject: [office] Conformance Clause proposal, Version 8
> 
> Dear TC members,
> 
> when I look over the discussions regarding the conformance clauses, it
> seems to me that there is actually a very large area of consensus, and
> that there are only a few, but essential items where the opinions
> differ. These are:
> 
> - Should there be a loose conformance level for documents that allows
> foreign elements everywhere?
> - Can we remove that level, that we had in ODF 1.1, without prior 
notice?
> - Should/Can we demand that a conforming producer must be able to create
> (strictly) conforming documents?
> 
> In addition to this, there seems to be a strong demand for a conformance
> level which does not allow foreign elements, and also for having a very 
> limited number of conformance level. My impression is that we agree all 
> agree on this.
> 
> The requirements are to some degree conflicting, but I anyway tried to
> find a solution that may be acceptable to all of you. The key points of
> it are:
> 
> - There will be two conformance levels for documents. One does not
> support foreign elements and is called "OpenDocument document
> conformance". The other one does support foreign elements without
> restrictions and is called "OpenDocument Host Language Conformance".
> - There will be two conformance modes for producers. A conforming
> OpenDocument document producer must be able to produce conforming
> OpenDocument documents. A conforming OpenDocument Host Language Producer
> must be able to produce OpenDocument Host Language Documents, but there
> is no requirement that it must be able to produce conforming
> OpenDocument documents.
> 
> This proposals meets the requirement to have a strict OpenDocument
> conformance, but it also provides a conformance mode for application
> that wish to extend OpenDocument. This means that we have two
> conformance levels rather than one, but the new name of what I called
> "loose" conformance in prior proposals better reflects the
> characteristics of this mode. And it lowers the risk of confusion. The
> proposal also provides a conformance mode for ODF 1.1 documents that
> contain foreign elements and shall be adapted to ODF 1.2.
> 
> The new name "OpenDocument host language conformance" is actually a name
> I have adopted from the XHTML 1.1 specification, which provides a "XHTML
> host language document" conformance level. It describes XHTML documents
> that make use of extensions modules. In so far, we would be very close 
> to XHTML in this regard.
> 
> The update proposal can be found here:
> 
> 
http://www.oasis-open.org/committees/download.php/31052/conformance-definiti

> on-proposal-v8.odt
> 
> The version I'm referring to is the first one in the document.
> 
> I have made a few non substantial corrections and clarifications, most 
> of them have been suggested by Rob (Rob, thanks for having a close look 
> at the proposal). A list of these changes can be found in the proposal 
> itself.
> 
> I would be glad if this proposal is acceptable for all of you and would
> like to discuss and maybe vote on it on Monday.
> 
> Best regards
> 
> Michael
> 
> 
> 
> -- 
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
> 
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>       D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



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