Re: XLink conformance criteria question

Henry S. Thompson wrote:
> OK, so if you have the patience, one more time for the slow-witted:
> is this an XLink problem or an SVG problem?

That was basically the question I asked on this list originally, yes.  I asked 
whether the way SVG was using XLink was acceptable, and if so how UA 
implementors were to handle the differences.  So far, the answer I've gotten 
have been "What SVG doing is fine as far as XLink is concerned."  Which means 
it's an XLink problem, as far as I can tell, in that it allows specs to reuse in 
ways that cannot be implemented with a generic XLink processor.  Then again, 
it's not clear to me that this is even a design criterion for XLink -- no one 
gave me a straight answer to that.

> In what way could XLink change to ameliorate the problem?

That depends on what the goals of XLink are, frankly.  If the idea is that 
languages reuse it somehow and define what the attributes should do in that 
language, then there's no problem -- everything is working as designed, and the 
language is just not meant for generic processing.  If, on the other hand, the 
idea is that you can implement XLink itself and get the implementation of XLink 
use in other namespaces as a result, then XLink probably needs to be a lot more 
strict about what a namespace reusing XLink can do with it.

Thank you for the speedy response,
-Boris

Received on Thursday, 15 March 2007 14:22:01 UTC