RE: [office-comment] Document processing: nonsensical paragraphs (ODF 1.2 CD01)

["Alex Brown" <alexb@griffinbrown.co.uk>]

Thanks Michael,

A follow-up comment:

I still have difficulty with the notion that an ODF processor will not
"parse" certain kinds of XML document. I think it's reasonable for a
reader to have in mind the XML sense of "parse" -- something that
continues unless there is some kind of data corruption or
well-formedness error. So, strictly speaking an ODF processor may
(logically) "parse" a document, but then reject it because it fails - in
essence - a validation requirement (the presence of foreign structures).

In practice of course, *programmers* tend to combine the activities of
parsing and validation into one process, but to be strict I think a
standard specification should maintain this distinction as it's quite
deeply rooted in the XML processing model.

Or maybe I'm being too pedantic ...

- Alex.

> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM]
> Sent: 02 March 2009 11:07
> To: Patrick Durusau
> Cc: Alex Brown; office-comment@lists.oasis-open.org; OpenDocument
> Mailing List
> Subject: Re: [office-comment] Document processing: nonsensical
> paragraphs (ODF 1.2 CD01)
> 
> Alex: Thank you for you feedback on this section:
> Patrick: Can you please correct the below errors for the next revision
> of the draft.
> 
> On 02/27/09 20:29, Alex Brown wrote:
> > 1.4.5 has:
> >
> > ----b
> > Conforming extended producers should not use foreign elements and
> > attributes for features defined in the OpenDocument schema.
> >
> > OpenDocument consumers should be able to parse documents that
contain
> > attribute values not specified within the OpenDocument schema. If an
> > attribute which has such an undefined value has a default value,
then
> a
> > conforming consumer should assume that the attribute has this value.
> > Otherwise, a conforming consumer should ignore the attribute.
> > ----e
> >
> > * What are "features defined in the OpenDocument schema"? the schema
> > defines purely syntax. Shouldn't this say "OpenDocument
> specification"
> > for the final two words?
> 
> Yes, it should say "OpenDocument specification" rather than
> "OpenDocument schema".
> 
> >
> > * In para 2 the ability to "parse documents" is mentioned. Any
> > conformant XML processor must be able to parse documents. Is "parse"
> > being used in a specialised and undefined way here? (Terms and
> > Definitions, again, may help here).
> 
> An ODF processor anyway may reject documents that contain undefined
> values, in so far, I think this requirement makes sense.
> 
> 
> >
> > * What are "attribute values not specified within the OpenDocument
> > schema"? if an id attribute has the value "id101" is that such a
> value?
> 
> We should better say:
> 
> "OpenDocument consumers should be able to parse documents that contain
> attribute values not *permitted by" the OpenDocument schema. If an
> attribute which has such an "not permitted* value has a default value,
> then a conforming consumer should assume that the attribute has this
> value.  Otherwise, a conforming consumer should ignore the attribute.
> 
> Michael
> 
> >
> > -- I take it this paragraph is meant to concern attributes with
> default
> > values declared in the schema. As it stands though, it makes no
> sense.
> >
> >
> >
> > --
> > This publicly archived list offers a means to provide input to the
> > OASIS Open Document Format for Office Applications (OpenDocument)
TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: office-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> > List help: office-comment-help@lists.oasis-open.org
> > List archive: http://lists.oasis-open.org/archives/office-comment/
> > Feedback License: http://www.oasis-
> open.org/who/ipr/feedback_license.pdf
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > Committee: http://www.oasis-
> open.org/committees/tc_home.php?wg_abbrev=office
> >
> 
> 
> --
> 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