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] Issue Comment Edited: (OFFICE-3440) ODF 1.2CD05 Part 1 Needs anyIRI datatype



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

Dennis Hamilton edited comment on OFFICE-3440 at 10/1/10 3:08 PM:
------------------------------------------------------------------

[update fixes one typo]

This proposal does not forbid any valid URIs or valid IRIs.  It forbids anyURI values that are not valid [RFC3987] IRIs.  If there is anything in this proposal that does not accomplish that, I will repair it.

In effect, this proposal IMPLEMENTS what Draft XSD 1.1 says we can do, if XSD 1.1 becomes adopted with that language.  So this proposal is also future-proofed.  (Thanks for providing the references to that material.)   I see no reason to borrow language from XSD 1.1 that is incompatible with the current language of [xmlschema-2], which is our normative reference.

The only significant change that could happen is that [RFC3987] is replaced.  There is indeed a project to produce a combination of [RFC3987] and [RFC3986], perhaps with extensions -- I lack information about that, as a future RFC.  That is too speculative at this point, and we can deal with that when it happens and to the extend it makes any difference for ODF.  Also, if you think about it, changes in RFCs that would impact existing IRI/URI resolvers will not happen quickly nor is it likely that anything will be broken in [RFC3987].  They are not going to break the web and it is unlikely that they will break ODF documents that stay within the provisions of [RFC3987].   In that regard, I find the IETF a serious trustworthy and reliable normative source with regard to safeguarding interoperability over time.

      was (Author: orcmid):
    This proposal does not forbid any valid URIs or valid IRIs.  It forbids anyURI values that are not valid [RFC3987] IRIs.  If there is anything in this proposal that does not accomplish that, I will repair it.

In effect, this proposal IMPLEMENTS what Draft XSD 1.1 says we can do, if XSD 1.1 becomes adopted with that language.  So this proposal is also future-proofed.  (Thanks for providing the references to that material.)   I see no reason to borrow language from XSD 1.1 that is incompatible with the current language of [xmlschema-2], which is our normative reference.

The only significant change that could happen is that [RFC3987] is replaced.  There is indeed a project to produce a combination of [RFC3987] and [RFC3986], perhaps with extensions -- I lack information about that, as a future RFC.  That is too speculative at this point, and we can deal with that when it happens and to the extend it makes any difference for ODF.  Also, if you think about it, changes in RFCs that would impact existing IRI/URI resolvers will not happen quickly nor is it likely that anything will be broken in [RFC3987].  They are not going to break the web and it is unlikely that they will bread ODF documents that stay within the provisions of [RFC3987].   In that regard, I find the IETF a serious trustworthy and reliable normative source with regard to safeguarding interoperability over time.
  
> ODF 1.2 CD05 Part 1 Needs anyIRI datatype
> -----------------------------------------
>
>                 Key: OFFICE-3440
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3440
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: Needs Discussion, Part 1 (Schema), Schema and Datatypes
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
>
>
> The rules for IRI references are slightly different than the rules for anyURI.  In particular, anyURI accepts ASCII characters that are excluded from IRI references by [RFC3987].
> Rather than qualify the use of anyURI to be specific to IRIs every place that anyURI is used in the current schema, it is recommended that this be handled in one place by introducing an anyIRI datatype that is  derivative of anyURI with an additional pattern constraint that eliminates the ASCII-corresponding characters that are excluded from IRI references in [RFC3987].

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