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] Commented: (OFFICE-2318) Public Comment: EBNF(ODF all versions) (CLONE)



    [ http://tools.oasis-open.org/issues/browse/OFFICE-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18846#action_18846 ] 

Dennis Hamilton commented on OFFICE-2318:
-----------------------------------------

I looked at IS 14977 a while back and I couldn't see it being at all useful for us.

I completely agree with Michael and David Wheeler on this.

MORE DISCUSSION

The [XML 1.0] notation works for us because it is specifically suited for structures that are concretely grounded on Unicode as a reference character set.  This applies to everything we are doing.  Also, we make use of XML Schema datatypes and syntactic forms defined in [XML 1.0] and [xml-names] using the [XML 1.0] notation.

With regard to David Wheeler's objections, the reason IS 14977 requires an explicit concatenation symbol is because spaces are allowed in the names of  syntactic forms and the "-" symbol has been taken for another purpose.  (It is interesting how difficult this makes defining the syntax using its own notation.)

The requirement for explicit termination of a production is not so odious because we require terminal characters to be in quotes, so there is no ambiguity with use of ";" as a terminator character.

Although it can't be done without backtracking, the use of "::=" is always a tip-off that the name on the left is not part of the preceding production rule.  These days, that is no hardship for a parser, but we don't worry about automatic parser generation in any case.  We humans seem to have no problem with this, especially when layout is used to guide recognition of the separation of productions.

My first reaction to IS 14977 is that it is a solution looking for a problem to solve.  On reflection, I see that they are addressing a genuine problem, but the solution is not very palatable and it shirks the problems of dealing with a concrete (reference) character set (even though it addresses that somewhat for representation of the syntactic notation itself).

In short, the design principles that IS 14977 addresses are simply too far-reaching and the result too complex for the specific case of Unicode/XML-related syntactic forms we find ourselves needing to express and/or rely on.

> Public Comment: EBNF (ODF all versions) (CLONE)
> -----------------------------------------------
>
>                 Key: OFFICE-2318
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2318
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: General
>    Affects Versions: ODF 1.2 Part 1 CD 4 
>            Reporter: Robert Weir 
>            Assignee: Patrick Durusau
>             Fix For: ODF 1.2 Part 1 CD 5
>
>
> Copied from office-comment list
> Original author: "Alex Brown" <alexb@griffinbrown.co.uk> 
> Original date: 22 Dec 2009 17:13:57 -0000
> Original URL: http://lists.oasis-open.org/archives/office-comment/200912/msg00017.html

-- 
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]