Re: Proposal for ISSUE-11: Default prefix declarations

Ben Adida wrote:
> On 3/3/10 9:46 AM, Mark Birbeck wrote:
>> I'll end by saying that this last point is why I don't like the idea
>> of default mappings
>
> +1. I think we have to be careful not to have too much "magic" in 
> RDFa. RDFa 1.0 is very simple to parse. RDFa 1.1 is gaining a number 
> of pro-author features, but we should strive to not make parsing full 
> of exceptions as a result.

Hmm... as the person who suggested this in the first place (at least, I 
think it was me) I should really speak for the proposal.  Basically, I 
agree that there are risks associated with having a pre-defined 
'profile' of prefix mappings and keywords.  However, when I originally 
brought this up the 'URIs everywhere' proposal had not yet gained any 
traction.  In a world without URIs everywhere, having pre-defined prefix 
mappings is much lower risk.  There is no danger of such a CURIE being 
interpreted as a URI in some crazy future world where 'foaf' becomes a 
defined scheme.


But that doesn't really matter any more.  Since we seem to have agreed 
that URIs can be used in contexts where only CURIEs were permitted 
before, and also have agreed that CURIEs can be used where only 
SafeCURIEs were permitted before, hard-coding prefix definitions is no 
longer seen as a good idea.  But really, that was never the proposal. 
Not really.


So let's take it back a step.  I still want this feature.  And I never 
did see this as being any different than having profiles that a user 
could select from.  This was just to be the 'default profile', if you 
will.  Selecting a profile is equally risky, in my opinion.  If I author 
a document today and expressly select a profile that pre-defines a ton 
of stuff, including things I don't actually use (e.g., rdfs:) and then 
some clown decides rdfs is an interesting scheme name for HTTP...  the 
profile (and therefore my document) now has a collision.  I didn't use 
that prefix... but who's to say that something I included might not 
have?  Or might start using it later?


My point is that this is ALWAYS going to be a risk.  Note that we 
already have a 'default profile'.  Today that profile only contains 
keyword mappings, but it is a profile none-the-less.  Extending this 
'default profile' to include prefix mappings just means the risk applies 
to more documents. So what?  Does anyone here actually think that we are 
going to include in the default profile some prefix name that is likely 
to become a formal scheme name in the future?  Especially given that the 
climate is very much anti-new-schemes in the TAG and the IETF as far as 
I can tell?


Finally, what is the alternative?  That we require some announcement 
mechanism.  I have always pushed for this, and everyone always says we 
can't because people are unable to edit the 'head' of the document. Has 
that changed?  I don't think so.  If it has not changed, and the goal is 
to ease authoring and in particular cut and paste... then I don't see an 
alternative other than a default profile that includes the things we 
deem interesting.


That's my story and I am sticking to it.


>
> I'm assuming we're going with full backwards compatibility, too, 
> right? Meaning that xmlns:dc="..." will always override whatever 
> default we have, with or without @profile?

I think this goes without saying.  Defining a prefix mapping in line is 
always going to work.  Has to, really.

>
> -Ben

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Monday, 8 March 2010 20:36:40 UTC