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: [OASIS Issue Tracker] Updated: (OFFICE-3491) 19.598 table:conditionsyntax ambiguity

     [ http://tools.oasis-open.org/issues/browse/OFFICE-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Brauer updated OFFICE-3491:

    Component/s:     (was: Needs Discussion)

This issue has been set to resolved after the needs discussion flag has been set. I strongly assume the resolution reflects the result of the discussion, and therefore will remove the needs discussion.

> 19.598 table:condition syntax ambiguity
> ---------------------------------------
>                 Key: OFFICE-3491
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3491
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Part 1 (Schema), Table
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
> The special syntax for table:condition is ambiguous.
> In the first paragraph, it is said that the namespace prefix (default or otherwise) applies to the syntax and semantics of values, strings, and expressions. 
> To then stipulate the syntax of *value* and *string* is peculiar. 
> I think the repair should be in the first paragraph, where the namespace governs only the syntax and semantics of the *expression* pattern. This allows simple table:condition forms that avoid dependence on any separate formula specification altogether. 
> However it does mean that we have trouble when an *expression* under the namespace has exactly the same lexical appearance as what is defined here as a *value* or *string* pattern. I would suggest that the *value* and *string* rules would have precedence and *expression* is to be considered only when the the occurence is not a well-formed *value* or *string*. 
> Finally, I note that the statement about leading "=" is worded as if it is a restriction on Part 2. I believe there is a separate proposal to strike that. 
> The repair to this should allow a table:condition that has simple values and strings as operands without any use of namespace-determined expressions.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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