[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-comment] Document processing: nonsensical paragraphs (ODF 1.2 CD01)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]