Re: Consensus on alternate prefixing mechanism

Martin,

I feel strongly that reliance on the xml namespace attributes as a 
prefixing mechanism was a design error, and that we need to fix it going 
forward.  It is an impediment to adoption of RDFa, and it causes no end 
of confusion.  Just look at the other messages in this thread where even 
the AUTHOR refers to CURIE-referenced vocabularies as namespaces.  They 
are not namespaces.  Namespaces in XML have a very specific definition, 
and nothing we have done in RDFa nor with CURIEs conforms to that 
definition.  But I digress...

More inline...

Martin McEvoy wrote:
>>  
> Hello Manu Ivan , thank you Manu for documenting this.
>
> Im still a little unsure of why RDFa should support an alternate 
> prefixing mechanism,  its never a good thing in my view to support two 
> ways of doing the same thing?
This is a fair point.   Unfortunately, it would be impossible at this 
point to remove the current xmlns-based mechanism.  We could deprecate 
it, and in some mythical future remove it, it that seems the best 
course.  But we have to remain compatible with our existing base of 
users and growing base of documents.
>
> I really do not like the @prefix mechanism at all it seems intuitive 
> and a little "hackish". If RDFa really neds to support such a 
> mechanism I am more in favour of re-using what we already have and not 
> thinking of something new, @content seem ideal for this purpose
>
> <div content="foaf=http://xmlns.com/foaf/0.1/"
>     rel="foaf:page"
>     typeof="foaf:Document">
I am not sure why you think that this use of content would convey the 
idea of a prefix definition?  @content has a specific mean - one of 
defining the object for a subject... in this case I think you would be 
producing a triple where some parent @about set the subject, the 
relation was foaf:page, and the object was the string foaf=... with a 
type annotation of foaf:Document. 

I could see trying to define prefixes using our existing mechanisms and 
a reserved "rel" value.  e.g. <div about="myPrefix" rel="prefix" 
resource="http://my.prefix.url/">...  but such a mechanism would not 
scale to the definition of multiple prefixes on a single element, and 
that is a requirement.
> ....
> ....
> </div>
>
> multiple prefixes can also declared in this way eg: 
> @content="foaf=http://xmlns.com/foaf/0.1/ 
> dct=http://purl.org/dc/terms/". I prefer @content over @prefix because 
> authors already know what it means.
>
> I dont believe any of these should be legal
>
> * foo=
>        # would this default to the current document?
>
> * =http://someuri.com/
>        # why would you want to overide the default namespace?
Its not a default namespace.  That's really really really important and 
people just keep forgetting it.  Which implies a design error.  It is 
the default prefix mapping for a CURIE.  Some people would like to be 
able to extend the collection of "reserved" words that are handled via 
rel and rev.  We have designed mechanisms for that.  Others would like 
to be able to define a default vocabulary prefix for a document, so that 
in the context of a document or the context of an element un-prefixed 
CURIEs would be considered in that vocabulary.  This is mainly a means 
of attracting people who don't like typing colons, as far as I can 
tell.  I don't mind introducing such a thing, but feel that extending 
the collection of reserved values is a more sensible way to address the 
problem.  And I don't feel that should be done via @prefix at all.
>
> * xmlns:foo="http://foo.com" @prefix="foo=http://bar.com/"
>       # on the same element seems pointless as you cant really 
> differentiate the URI's, you cant do that in RDF so why should you be 
> able to do that in RDFa?
We need to define a rule if we are permitting both.  Would it be silly 
to mix them?  Of course it would.  In my opinion, the rule MUST be that 
xmlns: takes precedence.
>
> * I also think this should be Illegal  @prefix="audio= 
> http://purl.org/media/audio# video = http://purl.org/media/video#"
>       # spaces between the "=" equals.
I'm not a big fan of it, but it doesn't hurt anything and Manu and 
others felt strongly that users are idiots and the more permissive we 
are the less likely it will be that people will get frustrated.
>
>
> Thank you.
>

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

Received on Thursday, 30 April 2009 14:56:44 UTC