[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=19179#action_19179 ]
Dennis Hamilton commented on OFFICE-2318:
-----------------------------------------
I don't understand the resistance here.
1. First, and most serious, the EBNF grammar as written is ambiguous. There no rule in EBNF, or BNF generally, that the longest match deepest in the patterns always wins. There is also no rule that says backtracking won't be necessary to parse correctly. To wit,
1.1 The longest match only wins when that is the only way to correctly parse the expression.
1.2 With the current EBNF grammar, if the complete expression is "(?abcd)" it is actually the case that "abcd" is the name because anything else fails to satisfy the grammer. I trust the implementation this grammar is intended to reflect handles that properly.
1.3 On the other hand, if I write "(?abcd)+(?x )" there are *two* ways to parse this according to the EBNF as written. One has the (first) name be "abcd" as before. The second is to have the name be "abcd)+(?x" and there is no second name in the parse.
1.4 Maybe if you capitalize Name, it does permit taking the longest winner, but I can find no explanation in [XML 1.0] of what it actually means to assert that something is regular by capitalizing the name of its pattern rule(s). I assume that such capitalization is meant to be informative, not prescriptive, since there is no reference, normative or otherwise, to further information on the topic.
2. With regard to white space, It is not a matter of whether or not it is useful to use other whitespace in attributes, but how the grammar permits their occurrence and where it does not. Do you really mean for expression "?&xA;" to be accepted?
2.1 Can we assume here that attribute-value normalization has already been done in accordance with [XML1.0] 3.3.3 the attribute before the grammar is applied? In that case, why allow more than #20 ? Even for a CDATA value (which I assume is what we are talking about), the only way #x9 (#xD, and #xA) can show up is via an explicit entity reference of some sort, just as that is the only way "<" and "&" can occur.
2.2 Why make more edge cases? There are enough already, but at least XML practitioners (and good XML processor implementations) are prepared to deal with those.
> 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]