- From: Alex Milowski <alex@milowski.com>
- Date: Mon, 22 Oct 2012 06:45:45 -0700
- To: Peter Danielsen <wiscal@gmail.com>, W3C RDFWA WG <public-rdfa-wg@w3.org>
Hello all, I've not been on the public-rdfa list till just now ... just the public-rdfa-wg list. So, I just saw the e-mail that Peter sent out [1] as he forwarded Manu's response to me. So, the processor with the issue is mine. :( As I can see, there is no test for this. I sent a note out on Oct 2nd about that but it wasn't tied to a detailed explanation like Peter sent. I am also happy to write up some test cases for this as well. There are two problems here: 1. Should it be resolved at all? We may want prefix resolution to be consistent with XML namespaces. In section 2.2 [2], it says the use of relative paths is deprecated according to [3] and that further specifications will provide no interpretation of the relative URI values. From the perspective of this decision, the namespace name is the relative URI even though it has further interpretation as a resolved absolute URI. The @prefix attribute could behave similarly. Since RDFa needs the output to be absolute URI values and the recommendations of [3] indicates that specifications shouldn't interpret relative namespace name URIs, if we wish the @prefix to be consistent with XML Namespaces, we shouldn't as well. In fact, I would say we could go further and say that relative prefix values are ignored. The other option is to say that since @prefix isn't a namespace name declaration, we're allowed to have our own interpretations. This would be inconsistent with XML Namespaces but enable the intended behavior that Peter wants for the uses he has described. As a user, I'll never use relative URI values for prefixes per the recommendations of [3]. As an implementor, I just want to know what to do: ignore or resolve? Using mappings to relative URIs, which is what my implementation does, per 7.5, step 3, is just broken as it results in relative URIs in the output graph. 2. If it is resolved, what should it be? The unresolved question for an implementor is this: Is the prefix resolved against the base URI where the prefix is declared or against the base URI on the element where it is used? That is, an xml:base could change the resolving base URI if it is allowed to be resolved at use. As an implementor, I would prefer the case where it is resolved at declaration as it would mean I can resolve it once. As a user, I think resolving it where it is declared makes more sense because it will have the same result everywhere. Also, it is somewhat pathological to resolve prefixes with relative URIs at use as different element base URIs will result in different mappings to absolute URIs. In either case, the resulting URI is inconsistent with namespace prefix declarations. Meanwhile, 7.5, step 3, says: "Regardless of how the mapping is declared, the value to be mapped must be converted to lower case, and the IRI is not processed in any way; in particular if it is a relative path it must not be resolved against the current base. Authors should not use relative paths as the IRI." Also, 7.4.1 could be interpreted to indicate that it expands where it is used. As such, if the WG intended it to be expanded where it was declared, it should probably state that in the errata. [1] http://lists.w3.org/Archives/Public/public-rdfa/2012Oct/0000.html [2] http://www.w3.org/TR/REC-xml-names/#iri-use [3] http://www.w3.org/2000/09/xppa -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics
Received on Monday, 22 October 2012 13:46:13 UTC