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-2235) Part 3 section 6.3.1and manifest schema: datatype namespacedToken incorrectly defined



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

Michael Brauer commented on OFFICE-2235:
----------------------------------------

Dennis: My assumption is as well that a pattern is an additional constrain that must apply in addition to the QName constrains. That means, the pattern itself may actually allow values that are not QNames, but the resulting names anyway must be QNames. So, I believe the pattern "[^:]+:[^:]+" does what you are looking for. But it may be confusing to permit values in the pattern that are not valid QNames.

If we want to be more restrictive, we have to map NCNameChar, Letter, etc. from the XML Namespaces BNF to regular expressions. I'm not feeling comfortable doing so for the reasons I have stated, but maybe you can propose a regular expression?

Otherwise I'm fine with adding the "^:]+:[^:]+" pattern restriction if someone confirms that our assumption that patterns may be less restrictive than the base types is correct, and if we believe that adding that pattern does not result in more confusion than the current solution.

> 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

        


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