Re: Consensus on alternate prefixing mechanism

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

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