- From: Chris Lilley <chris@w3.org>
- Date: Mon, 14 Jun 2004 14:41:47 +0200
- To: Dean Jackson <dean@w3.org>
- Cc: Ian Hickson <ian@hixie.ch>, Jim Ley <jim@jibbering.com>, www-svg@w3.org
On Monday, June 14, 2004, 2:32:46 PM, Dean wrote: DJ> Sincere apologies for the top-reply. I'm a little confused as DJ> to what bits have been answered, what bits haven't and what are DJ> errors in the spec. Can someone summarise please? DJ> Ian, for the xlink:type="simple" attribute: that's a good DJ> question. I'm not sure we ever thought about that. I'd guess DJ> that the wording about attributes from other namespaces wasn't DJ> thinking about xlink. Correct. It was mainly saying, don't go extending SVG in the SVG namespace. Put your other stuff in your own namespace. Although, we couldn't really tell people what to do with the XLink namespace anyway. DJ> Dean DJ> On Sat 12 Jun 2004, Ian Hickson wrote: >> >> On Sun, 13 Jun 2004, Jim Ley wrote: >> >>> >> >>> It's not a conforming SVG document fragment as per G.2. >> >>> http://www.w3.org/TR/SVG11/conform.html what viewers should do with >> >>> non-conforming SVG documents isn't specificied, just what viewers have >> >>> to do with conforming ones. >> >> >> >> No, SVG goes on at length about how documents that are "in error" >> >> should be handled (F.2). >> > >> > F.2 says clearly that: >> >| When an element has an attribute or property value >> >| which is not permissible according to this specification >> > >> > And xlink:href on rect is not permissable according to the >> > specification, Antoine provided the link. >> >> We're not talking about attribute or property _values_, but entire >> attributes, which is the bullet point prior to the one you quoted, which >> reads: >> >> # When an element or attribute is encountered in the document which is not >> # part of the SVG DTD and which is not properly identified as being part >> # of another namespace >> >> ...but in this case, it _is_ properly identified as being part of another >> namespace, namely the XLink namespace. >> >> >> >>> It ain't an SVG document fragment, what happens to it is up to you... >> >> >> >> It seems odd to me that SVG would _intentionally_ leave just three >> >> cases undefined >> > >> > I assume you're asserting the intentionally based on some other sources? >> > as it could of course be an oversight, they're quite common in >> > specifications >> >> Sorry, I had understood you were implying that it was intentionally >> undefined. Yes, I would say it is just an error in the specification. >> >> >> > and by my reading none of your cases are actually that undefined, the >> > xlink attribute is dealt with by the quote above, >> >> I don't believe so, as explained above. >> >> >> > the other two examples are equivalent, and as I say G2 deals with those. >> >> As mentioned before, G.2 doesn't say what a conformant implementaton would >> do, it only says that the given documents are not conformant documents. If >> it said they were /in error/ then it would be a different matter, but it >> doesn't. (The term "in error" has special meaning in the SVG spec.) >> >> -- >> Ian Hickson U+1047E )\._.,--....,'``. fL >> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Monday, 14 June 2004 08:41:52 UTC