Re: Prefixes fail-safe registry thoughts

Manu Sporny wrote:
> ...
>> Minimally, this issue should be addressed for @rel, because it affects
>> even non-RDFa use cases.
> 
> Do you think that this proposal could address your issue with @rel?

"My" issue with @rel is that I'd like to see a single interpretation 
across all HTML languages. For that, the conflict between URI and CURIE 
syntax would need to be resolved.

>> But that does change the rules for XHTML, doesn't it? Or are you saying
>> that XHTML != XHTML5 (== HTML5 serialized as XML)?
> 
> Not speaking as a member of the RDFa TF... just kicking around some ideas...
> 
> Yes, it does change the rules slightly, but shouldn't create any
> backwards-incompatible changes. That's what I should have said:
> 
> "The @prefix addition would not create any backwards-incompatible
> issues, nor would it adversely affect the processing rules. All of the
> 'XHTML+RDFa 1.0' documents would continue to work."

Yes, it's backwards compatible with existing valid XHTML+RDFa1.0 documents.

But (IMHO) XHTML+RDFa1.0 is already incompatible with other languages 
(see the long exchange over on the TAG mailing list from last weekend).

> ...
>> On the other hand, it will make the owners of purl.org extremely
>> unhappy, unless it doesn't happen frequently. (Did you talk to them?)
> 
> If the anti-indirection crowd is correct, it will happen quite
> frequently. If the pro-indirection crowd is correct, it will happen
> infrequently. We should plan for the worst.

In particular, as if opens up a simple DOS scenario against that server.

> I used purl.org as an example - any redirection service would do.  I
> haven't talked to the purl.org folks yet - don't know who to contact
> there. I also need to talk to them about http://purl.org/media# not
> resolving, but http://purl.org/media/# resolving. Do you know who I
> should talk to?

Nope, sorry.

Speaking of that: redirection is nice for delegating the authority, but 
of course is costly (it doubles the number of requests, and potentially 
the redirect will not be cached).

BR, Julian

Received on Tuesday, 3 March 2009 17:20:31 UTC