Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2 CD 05
    • Fix Version/s: ODF 1.2 CD 06
    • Component/s: Public Review
    • Labels:
      None
    • Proposal:
      Hide
      Replace all occurrences of "URL" and "URI" with "IRI", except where "url" or "uri" appears as attribute value or as part of an attribute or element name.

      Support the use of IRI reference (the proper term in almost every usage in ODF) by a normative reference to [RFC3987] and introduce an anyIRI datatype to be perfectly clear how IRIs are to be allowed in the anyURI datatype.

      Limit considerations of iRI mappling to URLs for purpose of resolution to the special case in section 3 involving "Usage of IRIs in Packages." This is the only place where actual mapping to single-byte encodings matter.

      Show
      Replace all occurrences of "URL" and "URI" with "IRI", except where "url" or "uri" appears as attribute value or as part of an attribute or element name. Support the use of IRI reference (the proper term in almost every usage in ODF) by a normative reference to [RFC3987] and introduce an anyIRI datatype to be perfectly clear how IRIs are to be allowed in the anyURI datatype. Limit considerations of iRI mappling to URLs for purpose of resolution to the special case in section 3 involving "Usage of IRIs in Packages." This is the only place where actual mapping to single-byte encodings matter.

      Description

      There are over 20 places in ODF 1.2 CD05 Part 1 where the term "IRI" is used without reference or explanation. These are often in the same statement where URI/URL are used and it is not clear whether these are being assumed to be interchangeable or different.

      These mentions of IRI are too casual. We should perhaps establish that we assume all provisions for URI references in Part 1 are subject to IRI encoding and choose to use IRI consistently. We might need to be careful that we don't overstep existing provision on URIs used as part of attributes defined by other specifications, such as xhtml:href and xlink:href, however. We may also need to say more about URI references when they use XML Schema Datatype anyURI.

      Whatever we do, it is a defect to continue to use IRI casually and with neither definition nor reference to an authoritative source.

      This is related to the similar situation in ODF 1.2 CD05 Part 3, addressed by issue OFFICE-2685 and any resolution in part 1 should be consistent.

      There may also be need for IRI clarification, and clarification around the permissable use of relative URIs in OpenFormula when an OpenFormula expression employs a URI in one of its forms for a reference.

        Activity

        Hide
        Dennis Hamilton added a comment -
        Needs to be discussed and resolved in alignment with however this is cleared up for Part 3, including OFFICE-2685
        Show
        Dennis Hamilton added a comment - Needs to be discussed and resolved in alignment with however this is cleared up for Part 3, including OFFICE-2685
        Hide
        Robert Weir added a comment -
        This came up in the review of ODF 1.0. I thought that we confirmed that that point that the XML Schema type anyURI allows IRIs as well.

        So if we're consistently using anyURI for that data type, then we don't have a technical problem. But one could argue that there is an editorial issue if we're using different terms to mean the same thing, especially for readers who don't know they are equivalent.

        Of course, if there is anyplace where we are not using the anyURI type, then that could be a problem.
        Show
        Robert Weir added a comment - This came up in the review of ODF 1.0. I thought that we confirmed that that point that the XML Schema type anyURI allows IRIs as well. So if we're consistently using anyURI for that data type, then we don't have a technical problem. But one could argue that there is an editorial issue if we're using different terms to mean the same thing, especially for readers who don't know they are equivalent. Of course, if there is anyplace where we are not using the anyURI type, then that could be a problem.
        Hide
        Dennis Hamilton added a comment -
        It is true that the URI specification allows IRIs and anything that allows URIs allows IRIs. But that is like saying SMTP plaintext messages allow HTML messages or even XML. It is true, but it is true by a convention that is not part of URI (or SMTP plaintext) itself. (Using MIME enclosures solves this problem in a particular way, so that using plaintext as a carrier of a special markup is less common, but not prevented, as far as I know.)

        It is an out-of-band agreement that the encoding convention in URI be used and understood in a particular way that allows Unicode characters not permitted directly in a URI to be carried by following a specific convention on the use of encoding. (URI encoding is a single-byte encoding scheme. It encodes a single byte. To treat sequences of them as encodings of UTF-8 encodings of single Unicode code points is *not* part of the URI specification.

        If *we* intend that convention, we need to be very specific where it applies and where we use the term IRI. We should probably adopt IRI in all of those places and not use URI in the same breath. At the same time, we need to make sure that where we assert use of the IRI convention, we are dealing with data types or namespace provisions that accomodate that.

        I gather that we want to permit IRIs to be used to reference files within the same package (using relative URI references as the carrier). That means we also need to specifiy what that means in terms of how the name of the package file is is related to the various relative IRI-carrying URIs by which it can be referenced. (This is the job that needs to be dealt with in Part 3. The job in Part 1 has to do with making sure that all of the places where anyURI, xhtml:href, and xlink:href and other reference structures are used, including same-page references via URI fragment forms, how their relative URI references are IRI encodings. We need to determine whether we are we seeing exceptions related to the determination of a base tolerated in Part 3 and are there any other exceptions. In particular, is our use a deviation from what the specifications for those references under the namespace of other folks require (e.g., for RDF and for XML DSig), and have we made that deviation explicit and unambigous in the ODF specification?
        Show
        Dennis Hamilton added a comment - It is true that the URI specification allows IRIs and anything that allows URIs allows IRIs. But that is like saying SMTP plaintext messages allow HTML messages or even XML. It is true, but it is true by a convention that is not part of URI (or SMTP plaintext) itself. (Using MIME enclosures solves this problem in a particular way, so that using plaintext as a carrier of a special markup is less common, but not prevented, as far as I know.) It is an out-of-band agreement that the encoding convention in URI be used and understood in a particular way that allows Unicode characters not permitted directly in a URI to be carried by following a specific convention on the use of encoding. (URI encoding is a single-byte encoding scheme. It encodes a single byte. To treat sequences of them as encodings of UTF-8 encodings of single Unicode code points is *not* part of the URI specification. If *we* intend that convention, we need to be very specific where it applies and where we use the term IRI. We should probably adopt IRI in all of those places and not use URI in the same breath. At the same time, we need to make sure that where we assert use of the IRI convention, we are dealing with data types or namespace provisions that accomodate that. I gather that we want to permit IRIs to be used to reference files within the same package (using relative URI references as the carrier). That means we also need to specifiy what that means in terms of how the name of the package file is is related to the various relative IRI-carrying URIs by which it can be referenced. (This is the job that needs to be dealt with in Part 3. The job in Part 1 has to do with making sure that all of the places where anyURI, xhtml:href, and xlink:href and other reference structures are used, including same-page references via URI fragment forms, how their relative URI references are IRI encodings. We need to determine whether we are we seeing exceptions related to the determination of a base tolerated in Part 3 and are there any other exceptions. In particular, is our use a deviation from what the specifications for those references under the namespace of other folks require (e.g., for RDF and for XML DSig), and have we made that deviation explicit and unambigous in the ODF specification?
        Hide
        Patrick Durusau added a comment -
        Dennis,

        OK, agree we need to put in a reference for IRI and include that where it is cited.

        When you say:

        ****
        The job in Part 1 has to do with making sure that all of the places where anyURI, xhtml:href, and xlink:href and other reference structures are used, including same-page references via URI fragment forms, how their relative URI references are IRI encodings.
        ****

        Isn't it sufficient to compare anyURI, xhtml:href and xlink:href and any other IRI reference structures, now conveniently isolated in separate sections since if they are valid in one they are valid in all?

        Do you have an example of where "...their relative URI references are not IRI encodings?"

        Seems like that would be a better way to raise the issue. As well as focus any effort to answer it. BTW, the xlink:href attribute has all the elements that invoke it gathered together so it should not be difficult to see if we call out a reference that doesn't work under an IRI.

        Just a historical note: IRIs were added at the request of the CJK community.

        PS: If there are any modifications to the invocation of xlink:href, for example, that is not located with the xlink:href definition, that is an editorial error that I need to correct.
        Show
        Patrick Durusau added a comment - Dennis, OK, agree we need to put in a reference for IRI and include that where it is cited. When you say: **** The job in Part 1 has to do with making sure that all of the places where anyURI, xhtml:href, and xlink:href and other reference structures are used, including same-page references via URI fragment forms, how their relative URI references are IRI encodings. **** Isn't it sufficient to compare anyURI, xhtml:href and xlink:href and any other IRI reference structures, now conveniently isolated in separate sections since if they are valid in one they are valid in all? Do you have an example of where "...their relative URI references are not IRI encodings?" Seems like that would be a better way to raise the issue. As well as focus any effort to answer it. BTW, the xlink:href attribute has all the elements that invoke it gathered together so it should not be difficult to see if we call out a reference that doesn't work under an IRI. Just a historical note: IRIs were added at the request of the CJK community. PS: If there are any modifications to the invocation of xlink:href, for example, that is not located with the xlink:href definition, that is an editorial error that I need to correct.
        Hide
        Michael Brauer added a comment -
        Three comments:

        1. Rob is right that this issue came up during the review of ODF 1.0 in ISO. We used the term URI, and got a request to change this to IRI to make clear that ODF supports internationalized URIs. We confirmed that the XSD "anyURI" datatype supports IRIs.

        2. There are a few new ouccurences of URI and URL in ODF 1.2. Most of them need to be replaced with IRI, of course.

        3. Not everywhere we talk about IRIs we mean to define a datatype of an attribute, but we are using the term "IRI" also in an informal way. Which means, we are using the term often in the the same way as we talk about for instance a "date". When we say "date", we also do not mean a date in a particular representation, but just a date in the meaning it has in the English language. The representation of data is defined by the datatype specification of the attribute at hands. The same situation exists for the term IRIs. We use it often to refer to an internationalized IRI (without defining an representation of that). The representation of the IRI is then defined by the attribute's datatype. Well, the terms that are probably used more often in this situation are URL and URI, but we are not using these for the reasons stated in #1.
        Show
        Michael Brauer added a comment - Three comments: 1. Rob is right that this issue came up during the review of ODF 1.0 in ISO. We used the term URI, and got a request to change this to IRI to make clear that ODF supports internationalized URIs. We confirmed that the XSD "anyURI" datatype supports IRIs. 2. There are a few new ouccurences of URI and URL in ODF 1.2. Most of them need to be replaced with IRI, of course. 3. Not everywhere we talk about IRIs we mean to define a datatype of an attribute, but we are using the term "IRI" also in an informal way. Which means, we are using the term often in the the same way as we talk about for instance a "date". When we say "date", we also do not mean a date in a particular representation, but just a date in the meaning it has in the English language. The representation of data is defined by the datatype specification of the attribute at hands. The same situation exists for the term IRIs. We use it often to refer to an internationalized IRI (without defining an representation of that). The representation of the IRI is then defined by the attribute's datatype. Well, the terms that are probably used more often in this situation are URL and URI, but we are not using these for the reasons stated in #1.
        Hide
        Patrick Durusau added a comment -
        switch all references of URI to IRI as per meeting on 7 September 2010
        Show
        Patrick Durusau added a comment - switch all references of URI to IRI as per meeting on 7 September 2010
        Hide
        Dennis Hamilton added a comment -
        What meeting on 2010-09-07 ? This is not an OpenFormula-only issue.

        Also, there is more too it than simply changing from one acronym to another. We need a reference and we definitely do not want to say it is "informal." If we don't mean the official IRI encoding somewhere, we should be using it. Also, I don't recall anywhere that URI is used and meant to be something casual, no matter what the datatype is.
        Show
        Dennis Hamilton added a comment - What meeting on 2010-09-07 ? This is not an OpenFormula-only issue. Also, there is more too it than simply changing from one acronym to another. We need a reference and we definitely do not want to say it is "informal." If we don't mean the official IRI encoding somewhere, we should be using it. Also, I don't recall anywhere that URI is used and meant to be something casual, no matter what the datatype is.
        Hide
        Patrick Durusau added a comment -
        Dennis,

        The OpenFormula meeting today.

        And no, the discussion was not as superficial as the note would indicate.

        Yes we do need the formal reference which is RFC 3987 and we discussed how we would have to check our usage in packaging, etc. The note was just a reminder that we agreed to do all that. Actually we agreed to the change to IRI in ODF 1.0 going to ISO so that decision was made long ago and far away. The question now is to do that properly.
        Show
        Patrick Durusau added a comment - Dennis, The OpenFormula meeting today. And no, the discussion was not as superficial as the note would indicate. Yes we do need the formal reference which is RFC 3987 and we discussed how we would have to check our usage in packaging, etc. The note was just a reminder that we agreed to do all that. Actually we agreed to the change to IRI in ODF 1.0 going to ISO so that decision was made long ago and far away. The question now is to do that properly.
        Hide
        Dennis Hamilton added a comment -
        There is a wordy (on my part) exchange on the list with regard to IRI v. URI on the OpenFormula list.

        I should warn you that I have been pursuing an incorrect conclusion, but I thought it worth gathering this here for completeness of the discussion:

         * Dennis E. Hamilton: RE: [office-formula] Summary 2010-09-07 - IRI vs URI
          <http://lists.oasis-open.org/archives/office-formula/201009/msg00002.html>
          [I repeat an unsound claim I had been making]

         * Andreas J. Guelzow: RE: [office-formula] Summary 2010-09-07 - IRI vs URI
           <http://lists.oasis-open.org/archives/office-formula/201009/msg00004.html>
           [Andreas points to the specific place in [RFC3987] where it is explicit that every URI is an IRI (but not the reverse) by definition.]

         * Dennus E, Hamilton: RE: [ditto]
           <http://lists.oasis-open.org/archives/office-formula/201009/msg00005.html>
           I get what how the rules for mapping IRIs to pure URIs takes pure URIs through unchanged (and that is what the subset statement is about). Here I struggle with the other side of the mapping, trying to wrestle a way into separating clean URIs that only %-encode a limited set of Basic Latin character codes (via their UTF8/ASCII character encodings) and that also have the %-encoded mapping of UTF8 sequences for other Unicode code points. Then I throw more on top of that.

         * Dennis E. Hamilton: RE: [ditto]
           <http://lists.oasis-open.org/archives/office-formula/201009/msg00006.html>
           Saying it simpler but not as simple as the summary just above.

         * Andreas J. Guelzow: RE: [ditto]
           <http://lists.oasis-open.org/archives/office-formula/201009/msg00007.html>
           Pointing out that the subset business is clear and has nothing to do with the mapping

         * Dennis E. Hamilton: RE: [ditto]
           <http://lists.oasis-open.org/archives/office-formula/201009/msg00008.html>
           Agreeing with Andreas and struggling to figure out what we call the URIs that are mapped from IRIs that are not URIs, especially since we can't tell which those are unless we make restrictions on the URIs we will use.

        So I will point out what I think the consequences of this is in an additional comment and the editing of this issue.


        Show
        Dennis Hamilton added a comment - There is a wordy (on my part) exchange on the list with regard to IRI v. URI on the OpenFormula list. I should warn you that I have been pursuing an incorrect conclusion, but I thought it worth gathering this here for completeness of the discussion:  * Dennis E. Hamilton: RE: [office-formula] Summary 2010-09-07 - IRI vs URI   < http://lists.oasis-open.org/archives/office-formula/201009/msg00002.html >   [I repeat an unsound claim I had been making]  * Andreas J. Guelzow: RE: [office-formula] Summary 2010-09-07 - IRI vs URI    < http://lists.oasis-open.org/archives/office-formula/201009/msg00004.html >    [Andreas points to the specific place in [RFC3987] where it is explicit that every URI is an IRI (but not the reverse) by definition.]  * Dennus E, Hamilton: RE: [ditto]    < http://lists.oasis-open.org/archives/office-formula/201009/msg00005.html >    I get what how the rules for mapping IRIs to pure URIs takes pure URIs through unchanged (and that is what the subset statement is about). Here I struggle with the other side of the mapping, trying to wrestle a way into separating clean URIs that only %-encode a limited set of Basic Latin character codes (via their UTF8/ASCII character encodings) and that also have the %-encoded mapping of UTF8 sequences for other Unicode code points. Then I throw more on top of that.  * Dennis E. Hamilton: RE: [ditto]    < http://lists.oasis-open.org/archives/office-formula/201009/msg00006.html >    Saying it simpler but not as simple as the summary just above.  * Andreas J. Guelzow: RE: [ditto]    < http://lists.oasis-open.org/archives/office-formula/201009/msg00007.html >    Pointing out that the subset business is clear and has nothing to do with the mapping  * Dennis E. Hamilton: RE: [ditto]    < http://lists.oasis-open.org/archives/office-formula/201009/msg00008.html >    Agreeing with Andreas and struggling to figure out what we call the URIs that are mapped from IRIs that are not URIs, especially since we can't tell which those are unless we make restrictions on the URIs we will use. So I will point out what I think the consequences of this is in an additional comment and the editing of this issue.
        Hide
        Dennis Hamilton added a comment -
        I was off base.

        Here is the situation:

        1. The set of valid URIs is a subset of the valid IRIs.

         2. There is a mapping by which IRIs that are not URIs can be transformed into valid URIs.

         3. AN IRI IS NOT AUTOMATICALLY AVAILABLE TO USE ANYWHERE THAT A URI IS EXPECTED. For example, [xml-names] does not support IRIs as namespace URIs (though there is no such restriction on the prefix, if any the namespace is bound to and the local names, all of which can be general XML NCNames. There is a corresponding interdependency with the various usages of URIs in RDF.

         4. The use of the transformed URI in place of the non-URI IRI is acceptable anywhere that a URI is accepted, unless there are additional restrictions that prevent the particular case. However, it is misleading to say that IRIs are being allowed. IRIs that are not URIs are not being allowed and this needs to be clear in how we described the situation and what we call such URIs.

          5. IRI REFERENCES ARE PERMITTED DIRECTLY IN THE LEXICAL FORMS OF THE XML SCHEMA anyURI DATATYPE. IRI References are also permitted directly in the lexical forms of xlink:href attribute values (with some special rules for fragment identifiers).

        ADDITIONAL CONSIDERATIONS

          6. IT IS NECESSARY that any IRI Reference value BE CONVERTIBLE to a pure URI reference using procedures specified by the W3C for anyURI and xlink:href.

          7. IT IS NECESSARY TO SAY WHEN any IRI Reference is converted to a URI Reference for resolution purposes. This last probably impacts only Part 3 where resolution of Relative IRI references against manifest:full-path values (and related Zip directory file names) is required.

          8. To assure unambiguous conversion to and from a URI [Reference]s and unambiguous comparison of URI segments with segments in manifest:full-path values, it is desirable to minimize the use of %-encoding in IRIs themselves. One way is to never %-encode the single-byte character codes of those US-ASCII characters that don't have to be %-encoded in a URI segment and to always %-encode the single-byte character codes of those US-ASCII character repertoire that have to be %-encoded in a URI segment, whether or not the segment is the first or later one in a no-scheme relative reference. (Note: In this case, SP is always %-encoded as %20 and there is no difficulty supporting whitespace-separated lists of IRIs.)

          9. To ensure interoperability, no non-ASCII codes should be %-encoded in IRIs. The resulting URIs will not contain any %-encoded bytes that are part of anything but UTF8 code sequences. In this case, the IRI is always recoverable by restoring those Unicode characters whose UTF8 encoding requires more than one %-encoded byte. [Note: the Unicode characters having single-byte UTF-8 encodings are meant to be %-escaped in satisfaction of (8) and are not decoded lest they alter the URI syntax.

        Show
        Dennis Hamilton added a comment - I was off base. Here is the situation: 1. The set of valid URIs is a subset of the valid IRIs.  2. There is a mapping by which IRIs that are not URIs can be transformed into valid URIs.  3. AN IRI IS NOT AUTOMATICALLY AVAILABLE TO USE ANYWHERE THAT A URI IS EXPECTED. For example, [xml-names] does not support IRIs as namespace URIs (though there is no such restriction on the prefix, if any the namespace is bound to and the local names, all of which can be general XML NCNames. There is a corresponding interdependency with the various usages of URIs in RDF.  4. The use of the transformed URI in place of the non-URI IRI is acceptable anywhere that a URI is accepted, unless there are additional restrictions that prevent the particular case. However, it is misleading to say that IRIs are being allowed. IRIs that are not URIs are not being allowed and this needs to be clear in how we described the situation and what we call such URIs.   5. IRI REFERENCES ARE PERMITTED DIRECTLY IN THE LEXICAL FORMS OF THE XML SCHEMA anyURI DATATYPE. IRI References are also permitted directly in the lexical forms of xlink:href attribute values (with some special rules for fragment identifiers). ADDITIONAL CONSIDERATIONS   6. IT IS NECESSARY that any IRI Reference value BE CONVERTIBLE to a pure URI reference using procedures specified by the W3C for anyURI and xlink:href.   7. IT IS NECESSARY TO SAY WHEN any IRI Reference is converted to a URI Reference for resolution purposes. This last probably impacts only Part 3 where resolution of Relative IRI references against manifest:full-path values (and related Zip directory file names) is required.   8. To assure unambiguous conversion to and from a URI [Reference]s and unambiguous comparison of URI segments with segments in manifest:full-path values, it is desirable to minimize the use of %-encoding in IRIs themselves. One way is to never %-encode the single-byte character codes of those US-ASCII characters that don't have to be %-encoded in a URI segment and to always %-encode the single-byte character codes of those US-ASCII character repertoire that have to be %-encoded in a URI segment, whether or not the segment is the first or later one in a no-scheme relative reference. (Note: In this case, SP is always %-encoded as %20 and there is no difficulty supporting whitespace-separated lists of IRIs.)   9. To ensure interoperability, no non-ASCII codes should be %-encoded in IRIs. The resulting URIs will not contain any %-encoded bytes that are part of anything but UTF8 code sequences. In this case, the IRI is always recoverable by restoring those Unicode characters whose UTF8 encoding requires more than one %-encoded byte. [Note: the Unicode characters having single-byte UTF-8 encodings are meant to be %-escaped in satisfaction of (8) and are not decoded lest they alter the URI syntax.
        Hide
        Dennis Hamilton added a comment -
        Opened the issue and adjusted the proposal to reflect the subtasks. NEEDS-DISCUSSION removed from this part.
        Show
        Dennis Hamilton added a comment - Opened the issue and adjusted the proposal to reflect the subtasks. NEEDS-DISCUSSION removed from this part.
        Hide
        Michael Brauer added a comment -
        I think this issue can be closed since where are two sub issues now.
        Show
        Michael Brauer added a comment - I think this issue can be closed since where are two sub issues now.
        Hide
        Dennis Hamilton added a comment -
        OFFICE-3432 applies only to OpenFormula.

        The resolution of OFFICE-3440 does not completely resolve the present issue.

        The present issue speaks to how we mention IRI and IRI Reference in the prose of the specification. OFFICE-3440 is only about the use of anyIRI in place of anyURI, and only if it is accepted does it provide partial resolution the the top-level issue. I would keep this top-level open because how it is completed depends on the resolution of OFFICE-3440.
        Show
        Dennis Hamilton added a comment - OFFICE-3432 applies only to OpenFormula. The resolution of OFFICE-3440 does not completely resolve the present issue. The present issue speaks to how we mention IRI and IRI Reference in the prose of the specification. OFFICE-3440 is only about the use of anyIRI in place of anyURI, and only if it is accepted does it provide partial resolution the the top-level issue. I would keep this top-level open because how it is completed depends on the resolution of OFFICE-3440 .
        Hide
        Dennis Hamilton added a comment -
        I am leaving this not resolved because whether anything further is needed depends on whether OFFICE-3440 Holds up.
        Show
        Dennis Hamilton added a comment - I am leaving this not resolved because whether anything further is needed depends on whether OFFICE-3440 Holds up.
        Hide
        Michael Brauer added a comment -
        I've turned the issue type into a task so that Dennis may check the resolution of OFFICE-3440.
        Show
        Michael Brauer added a comment - I've turned the issue type into a task so that Dennis may check the resolution of OFFICE-3440 .
        Hide
        Dennis Hamilton added a comment -
        Patrick reminds me that there are a few uses of URI (rather than IRI) in the text of Part 1. I will take a look and see if they should be changed or not.
        Show
        Dennis Hamilton added a comment - Patrick reminds me that there are a few uses of URI (rather than IRI) in the text of Part 1. I will take a look and see if they should be changed or not.
        Hide
        Patrick Durusau added a comment -
        OK, at 19.906, in the generated attribute value section, we use "URIorSafeCURIE with a reference to 18.3.37.

        18.3.37, reports the name URIorSafeCURIE but the text correctly refers to an IRI or SafeCURIE under RDFa.

        BTW, the cover page uses URIs ;-)

        I think we can close this one but wanted to ask first.

        Say the first meeting in September?
        Show
        Patrick Durusau added a comment - OK, at 19.906, in the generated attribute value section, we use "URIorSafeCURIE with a reference to 18.3.37. 18.3.37, reports the name URIorSafeCURIE but the text correctly refers to an IRI or SafeCURIE under RDFa. BTW, the cover page uses URIs ;-) I think we can close this one but wanted to ask first. Say the first meeting in September?

          People

          • Assignee:
            Dennis Hamilton
            Reporter:
            Dennis Hamilton
          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: