OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: RE: [office-comment] PRD02 Pt 1 Conformance language non-sense


Dennis hi

> I can see that saying "the namespace prefix *in* a ... text:formula attribute
> *value* ... " might be better, but if you look at the definitions of those
> particular attributes you will see the relevant details.

Yes, that takes it towards being intelligible/implementable, but probably isn't enough to get us there.
 
> Does this help, and is that enough in the wording that would make this more
> clear?

A few questions:

1. The text mentions "*the* namespace prefix", but couldn't there be many (if a function has arguments which call functions e.g.)? Is what is really meant here something *like* "the namespace prefix of any function contained in the content of..."?

2. The current conformance clause mentions just syntax. But that rather defeats the point, since surely what is desired is that these OpenFormula formulas actually conform to OpenFormula in all regards?

3. This text does nothing explicit to rule-out the invention of new, non-standard, formulas in the OpenFormula namespace. Surely not!

4. Namespace "prefixes" in content are of course a notorious aspect of the XML technology family. Are these proper Namespace Prefixes (i.e. in-scope Namespace/prefix bindings per the W3C spec), or pseudo-prefixes? I notice that a conformance requirement for OpenDocument Spreadsheet Documents is that namespace prefixes should be "bound" (I take this as meaning using the xmlns mechanism). But this requirement is *not* repeated for non-spreadsheet documents, where functions may also occur. This requirement should be consistent across document types, otherwise implementation chaos could ensue.

So, to cover these points, I  would first re-word the conformance target 2.2.1(D.3) to something like:

"Any function in the content of a style:condition, table:condition, table:expression, table:formula or text:formula attribute that has a namespace prefix bound to the name "urn:oasis:names:tc:opendocument:xmlns:of:1.2", or which has no prefix, shall correspond to a function defined in Part 2 of this specification, and shall conform to the definition of that function." 

And then to solve the namespace prefix vs pseudo-prefix issue, move the conformance item 2.2.4(D) to 2.2.1 so that this aspect of the use of formula prefixes is properly covered for all ODF document types.

Does that make sense?

- Alex.
 
>  - Dennis
> 
> BACKGROUND
> 
> We're talking about an attribute *value* not its name.  We have a
> mechanism, used in various places in ODF, where an attribute value has the
> form of an [optional] NCName together with a following  ":" that is then
> followed by some further attribute value.  The NCName must be bound to a
> namespace and that namespace determines the syntax and semantics of
> some or all of the further attribute value.  (In the case of table:formula
> attribute values, it is all of the rest.)
> 
> This is not new in ODF, and we endeavored to improve it in ODF 1.2.
> Previously, it was somehow assumed that the ":" was part of the prefix but
> that is not true, and we modified things to say that when the [optional]
> prefix is present it must be separate from the remainder of the attribute
> value by a ":".  The omission of the Unicode Code Point is an oversight.
> 
> 
> -----Original Message-----
> From: Alex Brown [mailto:alexb@griffinbrown.co.uk]
> Sent: Friday, December 24, 2010 23:10
> To: office-comment@lists.oasis-open.org
> Subject: [office-comment] PRD02 Pt 1 Conformance language non-sense
> 
> Dear all,
> 
> ----b
> D.3)If the namespace prefix of a style:condition, table:condition,
> table:expression, table:formula or text:formula attribute is associated with
> the "urn:oasis:names:tc:opendocument:xmlns:of:1.2" namespace, or if a
> namespace prefix is omitted for any of these attributes, the syntax of any
> formula which is contained in the values of these attributes shall conform to
> part 2 of this specification.
> ----e
> 
> Walking through the first of these:
> 
> "If the namespace prefix of a style:condition [...] attribute" ...
> 
> [okay, that prefix is "style"]
> 
> ... "is associated with the "urn:oasis:names:tc:opendocument:xmlns:of:1.2"
> namespace"
> 
> [okay, so if the "style" prefix is bound to this URI ... but hang on, the prefix of
> a conformant style:condition attribute is defined elsewhere in the spec as
> having to be "urn:oasis:names:tc:opendocument:xmlns:style:1.0", so we're
> talking here about a non-conformant document]
> 
> ???
> 
> I think what was intended here was to say something about namespace
> prefixes used in these attributes' *values* - I think this needs some careful
> re-wording because as it stands it seems to be a nonsensical conformance
> target.
> 
> - Alex.
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __________________________________________________________
> ____________
> 
> --
> 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
> 
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __________________________________________________________
> ____________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


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