- From: Toby Inkster <tai@g5n.co.uk>
- Date: Fri, 12 Mar 2010 09:30:55 +0000
- To: Ben Adida <ben@adida.net>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
On Thu, 2010-03-11 at 15:39 -0800, Ben Adida wrote:
> I'm still worried about inheriting prefixes from @profile, so I'm not
> sure we have consensus just yet.
The other problem is that it introduces a conflict with full URIs in
attributes.
e.g.
<div profile="http://example.com/vocab">
<span property="foo:bar">foo bar</span>
</div>
If example.com is down, the parser has no way of determining whether
"foo" is a CURIE prefix defined by the profile, or a URI scheme.
Using safe CURIEs, in the case where "foo" was intended as a CURIE
prefix, there is a non-ambiguous form:
<div profile="http://example.com/vocab">
<span property="[foo:bar]">foo bar</span>
</div>
However, advising authors to use safe CURIEs whenever a prefix was
defined in a profile seems like it's going to cause confusion.
And, if "foo" really was intended as a URI scheme, there's no "safe URI"
syntax, so when the profile document is unavailable, it's impossible to
unambiguously know what was intended.
I think there are three ways out of this:
1. We don't allow profiles to define prefixes;
2. We abandon full URIs in CURIE attributes; or
3. We define a safe URI syntax and insist that safe CURIEs
and safe URIs are used anywhere a profile is in scope.
I really don't like #3, and I'd rather drop profiles' ability to define
prefixes than drop full URIs.
--
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Friday, 12 March 2010 09:31:37 UTC