Re: Fine-tuning CURIEs (reply #2 :-)

Works for me, fwiw.  I don't think that having a default prefix (note 
that these are NOT namespaces.... don't get confused) is terribly useful 
in the XHTML case.  If you need to deal with things like openid.server, 
supply an appropriate GRDDL profile and transformation engine to "do the 
necessary".  As to how this gets addressed in the CURIE spec - that's 
for the CURIE spec.  Not relevant here IMHO.

Ben Adida wrote:
> Mark wrote:
>   
>> I haven't yet seen anything that convincingly says why we should
>> change the parsing rules for CURIEs such that they are no longer a
>> super-set of QNames, given that their whole purpose is to do what
>> QNames has been co-opted to do, but do it 'properly'.
>>     
>
> I think Ivan is right on this one: our thinking cannot depend on a
> future CURIE spec. We need to make things work with existing XHTML 1.1.
>
> So, with a CURIE-independent mindset, we can't have rel="openid.server"
> or rel="DC.creator" generate spurious triples. If we attempt this, we'll
> get killed at Last Call, just like we got killed for the spurious @class
> triples.
>
> I don't see any other solution than to say that "next" and "prev" are
> special-cased, using e.g. a pre-processing step, and any other
> non-namespaced values are ignored.
>
> If that changes in XHTML2, that's fine, of course. Consistency is not
> always possible when we have to be mostly backwards compatible with the
> existing web. But XHTML1.1+RDFa can't force authors to change their
> XHTML 1.1 too much.
>
> -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 Friday, 14 September 2007 00:14:33 UTC