Re: Consensus on alternate prefixing mechanism

Ivan Herman wrote:
> 
> Manu Sporny wrote:
>> Ivan Herman wrote:
>>> - Is the following acceptable: @prefix="=http://a.b.c/" ?
>>>  my option would be yes, and it sets the default namespace.
>>>  It could be equivalent to a xmlns="http://a.b.c/"
>> Most of this discussion about changing the default namespace has
>> happened offline over the past couple of months. During the telecons, we
>> didn't discuss in detail or form a consensus on how one would override
>> the default namespace.
>>
>> The other option that has been floated over the past couple of months
>> was using a reserved word, so something like:
>>
>> @prefix="DEFAULTNS=http://a.b.c/"
>>
> 
> I do not have very strong feeling about this but, I must admit, I am not
> sure I like the keyword approach, it adds yet another reserved term
> which is not good. I do not believe many people would use the default
> namespace stuff (after all, in 99% of the cases the default namespace is
> set by the surrounding language, eg, XHTML).
> 
> 
>> We could discuss further if a number of people felt that we needed a
>> mechanism to override the default namespace. It seems like we really
>> should define such a mechanism.
>>
>> Personally, I'd prefer a reserved word mechanism over the other method
>> because:
>>    * It would probably be easier for non-developers to understand.
> 
> 99.9% of the non-developers would not even consider this stuff in my
> view. They would just go with the namespace mechanism and rely on the
> surrounding language (XHTML) to have a default namespace. Ie, we should
> not go out of our way for this...
> 
>>    * It would be harder to mistakenly override the default namespace.
> 
> Yes, that is a reasonable point...
> 
>>    * It would be easier for the parser writers to handle.
>>
> 
> I am not sure of that...

I retract this! I just ran into the situation while testing and, indeed,
it can be a bit tricky if there is nothing on the left side of the '='.
It becomes more complicated to differentiate between

a=AAA =qqq

that might have been a legitimate use with qqq being a default namespace and

a= AAA=qqq

which is the 'illegal' usage of an empty URI (the point below).

Sigh...

Ivan


> 
>>> - Is the following acceptable: @prefix="aa="
>>>  my option would be no, this is an error, and the RDFa
>>>  processor should simply ignore that
>> I believe that the current regex would not match "aa=" and would thus
>> ignore it. However, if one were to do prefix="aa= bb=http://foo.com",
>> that may cause an issue. We should really have a couple of approved test
>> cases for these error conditions in the Design Suite. I'll try and take
>> an action to create some valid Design Suite test cases for @prefix.
>>
> 
> Ie, we agree that this is an error, right?
> 
>>> - What happens if there is, on an element, both an xmlns and a prefix?
>>> Ie, if I have
>>>
>>> <bla xmlns:aa="http://www.w1.com/" prefix="aa=http://www.w2.com/"/>
>>>
>>> what is the URI corresponding to the "aa" prefix? I know there were
>>> discussions on the task force, but it is not documented on the wiki...
>> There are currently mixed feelings on this. At first, we believed that
>> xmlns and prefix would exist in the same language, but now there are
>> concerns that this may confuse people (having two ways to do the same
>> thing). This issue can be worked through, so let's assume that prefix
>> and xmlns can be defined in the same document.
>>
>> I believe that the current consensus is that you would process both
>> lists, but one would take precedence over the other. 
> 
> I agree. We should be prepared to have both (although future DTD-s could
> make one or the other not well formed, but that is another matter).
> Other than that we would force our tools to run in two 'modes' which
> complicates matters.
> 
>>                                                       So, for example, if
>> @xmlns took precedence over @prefix, you would process @prefix first and
>> then @xmlns. Any conflicting mappings would be overwritten when @xmlns
>> is processed. The last defined value wins.
>>
> 
> Exactly. So here is the $1000 question: what is the precedence? At the
> moment, in my tool (on my machine, that is) @prefix has a higher
> precedence, ie, that one wins, but it is really throwing a dice, as far
> as I am concerned. We just have to document the result of throwing it
> and declare victory on that one... (I do not really see a significant
> advantage of one over the other)
> 
> Ivan
> 
> 
>> I have noted these issues on the rdfa.info wiki:
>>
>> http://rdfa.info/wiki/alternate-prefix-declaration-mechanism#Outstanding_Issues
>>
>> Anybody else disagree or have more input on these issues?
>>
>> -- manu
>>
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf