Hi Karl,
On Jul 03, 2006, at 08:32, [EMAIL PROTECTED] 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.
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.
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.
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.
Thanks again!
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
