OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

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

Subject: Change draft for #275: Internationalized Resource Identifiers

I pushed a change draft for Issue #275, “Specify how to store IRIs in URI-valued properties”:




We will move its adoption at TC #27 on Wednesday November 14th.


The core of this change is the new section 3.10.3, “Internationalized Resource Identifiers (IRIs)”, which clarifies that you can’t store an IRI (which is essentially a URI that’s allowed to contain non-ASCII characters) in a property that’s defined to contain a URI. It explains that you have to transform the IRI to a URI first.


In a sense this is a purely editorial change, even though the new section contains normative statements (“SHALL” and “SHALL NOT”). URI-valued properties have always been defined to contain URIs (RFC 3986) and not IRIs (RFC 3987). But a recent discussion with Aaron from Grammatech made me decide that it was important to be explicit on this point.


In addition to the new content, I moved some other content around. Until now, the section on fileLocation.uri included guidance on the use of URIs in general; that guidance applied to all URI-valued properties, so it didn’t really belong in the description of any particular one of those properties. As usual, you can view the change draft with Simple Markup for better reading, or in Full Markup to see where I’ve moved and deleted content.




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