[OASIS Issue Tracker] Commented: (OFFICE-2235) Part 3 section 6.3.1and manifest schema: datatype namespacedToken incorrectly defined

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Dennis Hamilton commented on OFFICE-2235:
-----------------------------------------

Michael, my understanding is that it is not necessary to map the QName BNF from [xml-names] to a regular expression.  The regular expression, just like a length parameter, is simply a constraint on the grammar that the QName datatype must already satisfy.  (It actually doesn't matter which order the two apply in, the QName grammar and the pattern regular-expression must both be satisfied.)

All that is necessary is to have a regular expression that requires a ":" to be present in what is otherwise a valid QName.  This singles out the prefixed case.  The other part is to require at least one Name-character in front of the ":" and at least one Name-character after it (excluding ":" from the Name-character set).  That's stricter than necessary, but it seemed more clear to do it that way.

The XML Schema datatype for QName specifically allows a regular expression pattern as a restriction (parameter in RNG parlance).  We tested this exact case for the Test Assertion Markup Language on the TAG TC and it works fine in XML Schema.  Applied against instances, the XML Schema validator used also confirmed that the document was Namespace well-formed, so the QName will be checked as part of that too.  It should work the same in the Relax NG because you are using the XML Schema datatypes. 

> Part 3 section 6.3.1 and manifest schema: datatype namespacedToken incorrectly defined
> --------------------------------------------------------------------------------------
>
>                 Key: OFFICE-2235
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2235
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Schema and Datatypes
>    Affects Versions: ODF 1.2 Part 3 CD 1
>         Environment: This issue applies in the Public Review documents ODF 1.2 Part 3 cd01 (files OpenDocument-v1.2-part3-cd1.pdf, OpenDocument-v1.2-part3-cd1.odt, and the HTML version at http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.html) and the companion schema file, OpenDocument-manifest-schema-v1.2-cd1.rng
>            Reporter: Dennis Hamilton
>            Assignee: Michael Brauer
>             Fix For: ODF 1.2
>
>
> In 6.3.1: 
> "A namespaced token is a token id that makes use of the XML namespace mechanism for modularization purposes."
> is vague and uninformative.  The form is not clear and the semantic conditions that apply are not stated (nor are modularization purposes explained and their achievement described).
> In the Manifest Schema, the definition
>     <define name="namespacedToken">
>             <data type="string">
>                     <param name="pattern">[0-9a-zA-Z_]+:[0-9a-zA-Z._\-]+</param>
>             </data>
>     </define>
> is not appropriate for an attribute whose values may be a QualifiedName and which should be Namespace Well-Formed.  The pattern does not properly allow NCName for the prefix and for the local name.
> See also OFFICE-2157 where this problem is corrected for ODF 1.2 Part 1.
> The only use of namespaceToken is as one of the alternative values of a manifest:preferred-view-mode attribute (section 3.8.11).  This attribute is new for ODF 1.2 manifest files and their is no impact of a remedy on backward-compatibility with earlier versions of ODF.

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