- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 26 Oct 2010 18:26:01 +0200
- To: Shane McCarron <shane@aptest.com>
- Cc: Mark Birbeck <mark.birbeck@webbackplane.com>, nathan@webr3.org, Toby Inkster <tai@g5n.co.uk>, public-rdfa-wg@w3.org, Martin McEvoy <martin@weborganics.co.uk>
- Message-Id: <C6D52528-FBE3-4197-B9FA-194D2814B9AE@w3.org>
On Oct 26, 2010, at 18:18 , Shane McCarron wrote: > I agree with Mark here. However, I also feel that we should encourage people to NOT do this for the same reasons we encourage people to not use relative URIs for prefix mappings. > I agree > Also, and correct me if I am wrong, don't we need to fully resolve any relative URIs in order to implant them in attributes within an XMLLiteral serialization? Sigh. Yes but... do we do that with, say, the @src attribute value (that can also be relative)? If we really wanted to do that, that opens up a pandora's box. How do we know that a specific attribute value in a host language is a possibly relative URI, ie, we have to turn the relative URI into absolute? Does it mean that an application has to understand, say, the DTD of a host language? I am tempted to say that no, we just dump into an XML Literal whatever we find there essentially verbatim. We do generate the necessary xmlns statements to make everything valid, but we stop there. In the unlikely case when the author really wants an XML Literal, let him/her put, say, an xml:base statement or something similar. Let us not try to be too intelligent:-( Ivan > > On 10/26/2010 11:05 AM, Mark Birbeck wrote: >> Hi Nathan, >> >> As you and others have said, there is no problem here. >> >> But note also that the processing your refer to is already well >> described in the spec, at the top of section 7.4 'CURIE and URI >> Processing': >> >> Since RDFa is ultimately a means for transporting RDF, a key concept >> is the resource >> and its manifestation as a URI. RDF deals with complete URIs (not >> relative paths); when >> converting RDFa to triples, any relative URIs must be resolved >> relative to the base URI, >> using the algorithm defined in section 5 of RFC 3986 [URI], >> Reference Resolution. >> >> This means that whatever value is yielded by concatenating a term with >> the value in @vocab will be sorted out correctly when the combination >> is processed in relation to the base URI. >> >> The flip-side of that is that no special processing is required to >> manage @vocab, other than to store it, and then perform concatenation >> of an unrecognised term is spotted. In other words you don't need to >> resolve the URI in @vocab -- just use it as a prefix. This is in fact >> what the text already says in the second bullet of section 7.4.3 >> 'General Use of Terms in Attributes': >> >> Otherwise, if there is a local default vocabulary the URI is >> obtained by concatenating that >> value and the term. >> >> However, since relative URIs in @vocab has caused some confusion it >> might be an idea to add a note somewhere about their use. I'd suggest >> the end of section 7.4.3, with wording along the following lines: >> >> Note that as described at the top of this section all URIs are >> resolved against the base URI >> before being used to generate triples. This means that even relative >> URIs can be used to >> define a default vocabulary. >> >> Regards, >> >> Mark >> >> >> On Tue, Oct 26, 2010 at 4:21 PM, Nathan<nathan@webr3.org> wrote: >>> Ivan Herman wrote: >>>> On Oct 25, 2010, at 17:45 , Toby Inkster wrote: >>>> >>>>> On Mon, 25 Oct 2010 13:15:44 +0100 >>>>> Martin McEvoy<martin@weborganics.co.uk> wrote: >>>>> >>>>>> The second vocab attribute "2#" would resolve to >>>>>> http://example.com/base2#which may be wrong? >>>>> No, that's not how base works. Check this in a browser: >>>>> >>>>> <html> >>>>> <base href="http://example.com/base"> >>>>> <a href="2#">hover over this link, look at status bar</a> >>>>> </html> >>>>> >>>>>> I think @vocab should always be an absolute URI (easier to parse an >>>>>> less complicated) >>>>> We already need to support relative links in @about, @resource, @src >>>>> and @href, so supporting relative URIs in @vocab is not too much to ask >>>>> from a parser. >>>>> >>>>> Actually, re-reading the RDFa Core 1.1 spec, it seems we already allow >>>>> @vocab to be relative (or at least we don't seem to forbid it >>>>> anywhere). If so, then it seems my concerns are unwarranted, and >>>>> vocab="2#" is well-defined. >>>> That was my reading of the document, too. It is a URI, that can be >>>> relative. I do not think we have a problem here. >>> Likewise, I see no problem - every URI/IRI(-Reference) can (should) be >>> passed through a function which resolves it against the base prior to use. >>> >>> The algorithm [1] is well defined in RFC 3986 [URI], pointed to for usage by >>> RFC 3987 [IRI], handles everything from absolute through to fragments, and >>> is implemented in almost every environment where you find a URI. >>> >>> Thus all things considered, I don't see why one attribute (@vocab) should be >>> treated specially when best/current practise is to resolve all URIs that >>> appear anywhere in a document prior to usage. >>> >>> [1] http://tools.ietf.org/html/rfc3986#section-5.2.2 >>> >>> Best, >>> >>> Nathan >>> >>> > > -- > Shane P. McCarron Phone: +1 763 786-8160 x120 > Managing Director Fax: +1 763 786-8180 > ApTest Minnesota Inet: shane@aptest.com > > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 26 October 2010 16:25:35 UTC