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] Regarding Conformance Clauses


Michael,

I had to stop and think about this.   The only statement in ODF 1.0/IS
26300/ODF 1.1 seems to be this one:

   There are no rules regarding the elements and attributes that actually 
   have to be supported by conforming applications, except that applications
   should not use foreign elements and attributes for features defined in 
   the OpenDocument schema. 
 
In the latest conformance proposal (v8), the counterpart seems to be this
passage:

   (P1) A Conforming OpenDocument Consumer ...
        (P1.3) ... shall be able to parse any [v8-]conforming 
        OpenDocument documents, but it need not interpret the
        semantics of all elements, attributes, and attribute
        values.

I think it is relatively clear what "supported" means (interpretation and
production in conformance with this specification), although something more
explicit might be valuable.  I don't think "need not interpret" implies
anything about doing something "reasonable," and I know no normative
statement around reasonableness.  I also believe there is a way to say this
that handles your concern about text content showing up where it no longer
fits.  [I need to go check the XML nomenclature for content that consists of
possibly other elements with or without possible non-whitespace text.]

So while it might be useful to behave in the way you suggest, I don't think
a requirement for that behavior can be read into P1.3.  That is why I
propose to say something about how those unsupported elements MAY be
handled.  That would remain compatible with earlier potential treatment.
Saying how they SHOULD be handled might work if confined to
strictly-conformant consumers, since we have not had such a thing before and
we aren't breaking any precedent.

 - Dennis

PS: On further reading, I also notice that there is no consideration that a
conforming processor might be able to support a foreign element, attribute,
or attribute value and so it is not going to handle the foreign EAV in the
way described.  So it is strange to say that a [v8]-conforming processor
[read: consumer] SHOULD NOT interpret the element's content.  I think the
problem is that there are two flavors of document conformance but not
matching flavors of processing (consuming or producing) performance.  This
and other hiccups are perhaps best handled by wordsmithing a draft once the
basis principles are agreed to.
  
-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
http://lists.oasis-open.org/archives/office/200901/msg00185.html
Sent: Monday, January 26, 2009 06:24
To: dennis.hamilton@acm.org
Cc: 'OpenDocument Mailing List'
Subject: Re: [office] Regarding Conformance Clauses

Dennis,

On 01/26/09 04:00, Dennis E. Hamilton wrote:
http://lists.oasis-open.org/archives/office/200901/msg00184.html
> 2. With regard to P1.3, I think the statement should be stronger.  I think
> that if a conforming consumer does not interpret the semantics of an
> element, attribute, or attribute value, it SHOULD behave as if that were a
> foreign element, attribute, or attribute value (not sure there is such a
> thing as a foreign attribute value though).  We should also consider
whether

I don't think that we need that, and I'm also not sure if this would
really work.

The ODF specification defines the semantics of the elements it defines.
Whether a consumer that does not support a particular element has to
process the content of that element depends on whether there are child
elements it supports. Which means that the implementors of a consumer of
cause have to decide what action the consumer takes for all elements
that ODF defines, even if they don't support or do not fully support a
particular element. The difference to foreign elements is that they can
make that decision, because the ODF specification tells them what the
elements mean. That is not the case for foreign elements. For this
reason, we need some precise rules there.

> office:process-content could be used in those cases by document producers
in
> advising less-capable consumers of an appropriate action. 

Again, I don't think that is necessary. Even a less-capable application
has to take some reasonable action for elements it does not support.
What actions this is depends on the purpose of the specification. I
don't think that can be decided by an application that stores a
document, and which does not have any knowledge about the "less-capable"
application.

Furthermore, using the attribute for elements that ODF defines would
only increase the document size, but it would not add any value, because
the information whether it is reasonable to process an element or not 
can be found already in the specification.

[ ... ]



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