Re: XLink conformance criteria question

/ Boris Zbarsky <bzbarsky@mit.edu> was heard to say:
| Norman Walsh wrote:
|> The Core WG discussed these comments and we don't agree with your
|> analysis. While you're correct that the spec says "should", it says so
|> in the RFC2119 sense:
|
| I realize that.  This does not change the fact that violating the SHOULD does
| not make an application non-conformant.

That's true, provided there's some RFC2119 appropriate justification.

|> In other words, there may be applications for which the specified behaviors
|> are inappropriate
|
| Such as any UA implementing SVG?  This is the original context in which the
| problem arose; the issue has been raised with this working group before, I am
| told, and the SVG Working Group received an answer that contradicts the one I
| just got.  Please do see
| <http://lists.w3.org/Archives/Public/www-svg/2006Apr/0027.html>, which I cited
| in my original mail.

That mail seems pretty clear to me. Unless I misunderstand, the
combination of show/actuate that you've proposed in that message
isn't allowed by SVG. So the SVG semantics don't apply.

At this point you've got a new language. As I see it, that's either an
error which often means that all bets are off: the browser might
report the error, ignore the element, perform some corrective action,
etc.

If it's not an error, then the browser SHOULD obey the XLink
semantics. I think this probably argues in favor of treating it as an
error of some sort.

| That said, if we can actually have a meaningful discussion about the whole
| situation (at a faster rate than one mail every 5 months), perhaps we could
| still clarify the relationship between XLink and SVG...  As an implementor, I
| would mich appreciate that.

I can do nothing but abjectly apologize for my tardiness again. But I
do hope that I've shed some light on the relationship.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.