Re: Consensus on alternate prefixing mechanism

Hello Shane thanks for your kind reply

Shane McCarron wrote:
> 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.  
Thats true I guess...
> 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... 

Thats true in RDFa @content in html/xhtml is just meta data associated 
with some thing, character data, the contents can be anything, I guess 
re-using @content is not the best way forward....
> 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.

or just common terminology used by the web at large.....

> 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.

Sound over complex to me not simplifying or correcting anything....
>>
>> * 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.

should it? how about if the xmlns:foo="http://bar.com/" was set in the 
html tag of the document and later somewhere in the content someone used 
@prefix="foo=http://foo.com/"  would xmlns take precedence then?

>>
>> * 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.

I cant imagine that will happen very often but it seems to conflict with 
the default prefix rule mentioned above ie: =http://someuri.com/ or foo= 
I guess its not that important, it just makes parsing a little more 
complex..

>>
>>
>> Thank you.
>>
>

Best wishes

-- 
Martin McEvoy

http://weborganics.co.uk/

"You may find it hard to swallow the notion that anything as large and apparently inanimate as the Earth is alive."
Dr. James Lovelock, The Ages of Gaia

Received on Friday, 1 May 2009 10:53:27 UTC