- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 13 Sep 2007 19:09:54 +0000
- To: public-sml@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4632 ------- Comment #3 from cmsmcq@w3.org 2007-09-13 19:09 ------- Following on from the proposal in comment #2, see also the proposal from Kumar Pandit at http://lists.w3.org/Archives/Public/public-sml/2007Sep/0082.html which reads in part: Proposal: I propose that we should not refer to any specific URI/IRI RFC in the SML and SML-IF specs. Instead, we should let the definition of sml:uri be governed by the definition of xs:anyURI type defined in the schema version we align to. Reasons: 1. sml:uri is of type xs:anyURI as currently defined in the SML schema. This type supports encoding international characters using a well defined escaping scheme (http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI). SML instance documents can of course have internationalized content. Thus internationalization is possible without any change to the spec as it is defined today. 2. We have decided to align SML 1.1 spec with XML schema 1.0 which is aligned with URIs (RFC2396/2732). 3. Most XML schema 1.0 processor implementations do not support IRIs. This means that SML implementations that use an off-the-shelf schema 1.0 processor will need to provide additional implementation to support IRIs. Implementing RFC 3987 (46 pages long) is non-trivial amount of work. This is an unnecessary implementation burden given that internationalization is already possible as described in #1. 4. If we decide to align SML spec with XML schema 1.1 in a future release, we will automatically get IRI functionality as schema 1.1 is aligned with the IRI RFCs. 5. The SML spec does not put any restrictions on additional reference schemes that can be defined. If an application does not wish to use the internationalization support already provided by sml:uri (xs:anyURI) for reasons specific to its domain, it is free to define additional scheme(s) to meet its needs without violating the SML 1.1 specification. [end quotation] As a supporter of IRIs, I am happy with this. But I want to clarify one important technical issue. It needs to be noted that while XSDL 1.0 points to the URI spec, not the IRI spec, it's nevertheless true that the value space of xs:anyURI includes (as far as I know) all legal IRIs. So any library that "supports" xs:anyURI, for the relevant meaning of "support" will also "support" IRIs. (The anyURI type was designed to support IRIs; the XSDL 1.0 spec points to URIs not IRIs only for historical reasons.) The only difference I know of (there MAY be others, but I rather doubt it) between xs:anyURI and IRI is that after XSDL 1.0 was completed, a later revision of the IRI spec forbad blanks in IRIs. So "http://example.com/This is an example" is legal (though very odd) as an anyURI, but not as an IRI, where the nearest equivalent is "http://example.com/This%20is%20an%20example". That means I'm happy with Kumar's suggestion, but I am concerned lest he may support it out of the view that supporting xs:anyURI involves less than supporting IRIs. If he still supports his proposal after this clarification, then good.
Received on Thursday, 13 September 2007 19:10:02 UTC