Re: [comment-rex] XPath interoperability

Le 06-10-09 à 21:12, Robin Berjon a écrit :
> On Jul 03, 2006, at 08:32, karl@w3.org wrote:
>> [[[User-agents MAY support a superset of this syntax so long as it  
>> is a valid instance of the XPath language [XPATH]. Content  
>> producers however SHOULD NOT use such extensions as they hamper  
>> interoperability.]]]
>>
>> This is slippery (specifically when you are hunting dahut ;). If  
>> one user agent proposes the feature at a point in time where it  
>> dominates the market, everyone will use it. Another risk of user  
>> agent sniffing to send the right rex to the right user agent.
>
> Things are always slippery when you're hunting dahut, that's half  
> the fun!
>
> We are well-aware of what might happen if implementations start  
> using a larger subset, but equally we know that putting "don't do  
> that" in the specification is not going to change what will happen.  
> This clause is basically stating that it's a bad idea, while  
> recognising what will happen in reality.

understood.

>> What's happening when a author used the extended possibilities of  
>> a browser X but they are not supported in the browser Y?
>
> The path is considered invalid in UA Y, and therefore returns an  
> empty node-set.

Maybe that would be a way to give a practical example showing one of  
the possible problems related to extensibility.

>> Request a warning mechanism for user agent to inform users that  
>> the rex message contains XPath features which are not processable.
>
> The specification deliberately does not require UAs to inform the  
> end-user of errors, as that tends to either be impractical, or  
> simply not be implemented. They are however allowed to, and the  
> specification does not preclude lint-like products.

There is a good way to deal with errors in terms of software usability.
	no silent recovery except if the user says so. There can be an  
option so the user can be warned except if the user is asking not to  
be. (opt in/opt out)
>> A specific event could be sent by the browser so it will be  
>> machine identifiable as well.
>
> We considered this but have so far deferred it to a future version.  
> The reason for this is that v1 needs to be limited and simple, and  
> because there have not been requirements for this feature.

Maybe an appendix on plans for future potential versions or a link to  
a page giving a roadmap.


-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Tuesday, 10 October 2006 07:29:01 UTC