Eyes Above The Waves

Well said. Too bad no one knows how to save the sinking ship that is the W3C.
At this rate, 10 years from now, we'll all be writing for the Flash player out of lack of feasible alternatives for advanced web graphics. But at least we'll have some mighty fine "Recs" to read over for pure intellectual stimulation. I mean, what's better than a well written Rec, right?
Oh...yea. That's right. A widely adopted standard. Too bad the two seem to so rarely coincide.

Why does SVG have a target attribute anyway? Why doesn't XLink have a target attribute?
And why does SVG have a link element? If it isn't good enough to apply attributes to other elements, why doesn't XLink have a link element?
It seems to me that SVG is stepping way over the line, especially with the interactive stuff. SVG does still stand for Scalable Vector Graphics, doesn't it? I don't see how linking or interactivity is related to graphics.

It looks like this argument is based on a misunderstanding of the WebCGM spec by the SVG members. The WebCGM spec seems to me to be completely compatible with the de-facto HTML standard, given that iframes and objects also create frames. _replace only applies when the SVG elements are in the same document as the HTML elements. That is why the WebCGM spec shows _replace not to be compatible with CGM-to-HTML, because CGM and HTML cannot be in the same document.

There's more than what you are saying in this post.
Chris is saying too:
"What would make you satisfied? Are you asking us to change the behaviour so that it is no longer the same as WebCGM but instead is the same as what you describe as de-facto behavior of HTML implementations do? How would that help? It just moves the incompatibility from one place to another, and makes the spec incompatible with several W3C Recs rather than with some de-facto but underspecified behaviour."
Here is a good example of what is the real world. Nothing to do with "pure intellectual" specifications. (btw, I do not know what is a theoritical specification.)
Let's make it clearer.
Group A of the market is saying: "We want this feature implemented as we described and did in WebCGM Specification."
Group B of the market is saying: "We want this feature implemented as it has been done we HTML specification."
Conflicts between two markets in a real world. It's a tough issue. People forget that ol' good desktop browsers are not the only ones implementing the technologies.
There's also entering a CR phase, which is implementation demonstration. Real facts to see if it's possible or not to implement the feature. How about demonstrating it now, that it's possible or not possible.

Sjoerd: that's interesting, but for my illustration it actually doesn't matter whether the incompatibility is real or not.
karl: It should be completely clear to you and Chris that the correct answer is to make SVG compatible with HTML and not with WebCGM. This is so obvious that I shouldn't have to repeat myself, and I'm disturbed to find that I do, but here it is: There are many orders of magnitude more HTML authors, HTML documents, and installed HTML browsers than there are WebCGM authors, documents and viewers. The way to maximise compatibility in practice is to be compatible with HTML. End of story.
Also you can mix HTML with SVG, but you can't mix WebCGM with SVG.

Read me again: Market A and Market B. W3C Staff is the voice of WGs not the opposite. Mozilla Foundation is part of W3C but does not participate to SVG WG, though Opera is participating (for HTML Browsers).
SVG is used also by the same industry which is using WebCGM for example command console. There are many implementers in SVG WG from the mobile industry too, more than HTML browsers.
(Note that I'm just stating facts, not taking positions about who is right or not. I shouldn't have to repeat myself, I'm disturbed to find that I do.)

Last I checked, "W3" stood for World Wide Web. If the W3C favours the interests of the command console industry (whoever they are) over Web authors and users, it ought to change its name.
The mobile device industry is not relevant here since I don't believe they're interested in WebCGM. I will say that it is a shame that they have gained such sway over proceedings, since they seem to care more about their walled gardens of content than compatibility with the existing Web.
Your point might simply be that the W3C is driven by the agendas of its paid-up members and doesn't have much independent latitude. I'd agree with that, but I'd expect W3C staff to push back against Web-incompatible agendas, not endorse them.

I am quite confused by all these posts. We are talking about SVG Tiny 1.2 here. Emphasis on "Tiny". "Tiny" targets cellular phones, with specific viewers (SVG 1.2 Tiny viewers). This is what the real world is about.
Trying to push SVG Tiny 1.2 into some sort of genaralisation for the entire Web won't work. This is why SVG 1.2 "full" is for.
So we could certainly argue that we need to have perfect compatibility between SVG Tiny and SVG full. And this would certainly be a good point. But we have to consider that it took already 5 years at least to move from 1.1 to 1.2. Had the WG waited longer, the specs would have landed on a market with another de facto standard...
If we consider that a standard has to be something absolutely perfect with a global consensus, even at the expense of a total deconnection with the real world, then yes, the W3C is broken. If we believe as I do that the W3C should release useful specs, then don't fix it, ain't broken.

> But we have to consider that it took already 5
> years at least to move from 1.1 to 1.2.
That might have been reduced if the WG had not decided to expand the scope of SVG to include, for example, networking APIs.
> Trying to push SVG Tiny 1.2 into some sort of
> genaralisation for the entire Web won't work.
> This is why SVG 1.2 "full" is for.
OK. Then SVG Tiny should have a warning attached to it explaining that it is not intended for use on the Web.
> "Tiny" targets cellular phones, with specific
> viewers (SVG 1.2 Tiny viewers). This is what the
> real world is about.
So the world of billions of HTML documents and applications, a world that could benefit from vector graphics, is not real? Interesting perspective.
> If we consider that a standard has to be
> something absolutely perfect with a global
> consensus
Hello straw man argument.
> even at the expense of a total deconnection with
> the real world
Chris Lilley is saying it's more important to be compatible with WebCGM than HTML, and the charge of being disconnected from the real world falls on his objectors? Interesting perspective.
Nevertheless, even if we take your position at face value, it actually restates my point: for whatever reason, the SVG working group is disinterested in the Web as we know it.
All I ask is that its specifications be marked as not intended for use on the Web, so that browser vendors and other parties can produce alternative specifications that are Web-compatible without treading on anyone's toes.
I wonder whether it is appropriate for the W3C to be investing in standards that are not Web-compatible, but that's a lesser concern.

By the way, for readers who don't know the background, Marc works for Beatware who (as I understand it) are already shipping an SVG 1.2 Tiny viewer for cellphones and hence are eager to see the specification frozen as-is.
Also, they compete head-on with Flash Lite, and it's their need to compete with Flash using SVG alone that has led to inappropriate APIs such as networking being shoehorned into SVG in a very browser/HTML-unfriendly manner.

> By the way, for readers who don't know the
> background, Marc works for Beatware who (as I
> understand it) are already shipping an SVG 1.2
> Tiny viewer for cellphones and hence are eager
> to see the specification frozen as-is.
No. Beatware develops an authoring tool for SVG Tiny and Flash Lite. Freezing the specification is important for SVG Tiny, not for us. Most of our clients are already creating SVG Tiny 1.2 content anyway...
> Also, they compete head-on with Flash Lite,
> and it's their need to compete with Flash
> using SVG alone that has led to inappropriate
> APIs such as networking being shoehorned into
> SVG in a very browser/HTML-unfriendly manner.
I don't think so. Anyway, we are not members of the working group...
Networking API have been introduced in the spec so that something useful could be done with the standalone SVG Tiny viewers shipping with cellular phones.
You make me realize that there is clearly a confusion here. From the W3C web site: "The SVG Mobile Profiles: SVG Basic and SVG Tiny are targetted to resource-limited devices and are part of the 3GPP platform for third generation mobile phones".
Yes, the Web as you see it through browsers is very important but this has to be adressed by SVG Full, not by SVG Tiny.
Expecting the people working on SVG Tiny to hold on the spec to satisfy the Web browsers implementors is not reasonnable.

I stand corrected, thanks Marc.
I think we agree then that SVG 1.2 Tiny should be clearly marked as not Web compatible, and that SVG 1.2 Full should be Web compatible --- and therefre not compatible with SVG 1.2 Tiny --- and labelled as such.

> Most of our clients are already creating SVG Tiny
> 1.2 content anyway...
No they're not. SVG Tiny 1.2 doesn't exist yet. It's what you _want_ to be SVG Tiny 1.2, as Robert said.
> Trying to push SVG Tiny 1.2 into some sort of
> genaralisation for the entire Web won't work. This
> is why SVG 1.2 "full" is for.
If you're happy for SVG Tiny 1.2 to be incompatible with SVG Full 1.2, sure. To me, that's nuts. Better to give both specs different names and not confuse people.

> No they're not. SVG Tiny 1.2 doesn't exist
> yet. It's what you _want_ to be SVG Tiny 1.2,
> as Robert said.
What I would like SVG Tiny to be and what it is in the spec are two different things. And I don't have any influence that I know of on the spec.
> If you're happy for SVG Tiny 1.2 to be
> incompatible with SVG Full 1.2, sure. To me,
> that's nuts. Better to give both specs
> different names and not confuse people.
I am not sure I get your point here. Do you mean that because you don't need certain things from the SVG Tiny spec in a browser environment, we should get rid of them even at the expense of making the whole project useless? Come on...

What could have been done, and perhaps could still be done, is to put the Web-unfriendly features in a special annex, call it SVG 1.2 Mobile Extension, say, and make it clear that this is not to be implemented by Web browsers and will not be part of SVG 1.2 Full.

Robert, I do not agree with your statement that the SVG spec "defines <svg:a target="_self"> to work in a way that's incompatible with the de-facto standard implemented by all major browsers"
Look at http://vectoreal.com/w3c/link-target-test/. In the "_self" section in the left pane for HTML object you will see that Moz/Opera consider the HTML:object's rectangular area as _self while IE targets the "host frame". It is clear by these tests that "all major browsers" do not interpret _self consistently and that there is no de-facto standard for _self, at least where HTML:object is concerned.
If WHATWG's HTML5 spec makes its way to the W3C's HTML WG, then we have the definition of "browsing context" (instead of the over-used term "frame" in HTML 4.01). This spec outlines the behavior of target, HTML:object and HTML:a that is inconsistent with the leading implementation. But I hope it is ratified by the HTML WG and Microsoft agrees to it anyway because it makes more sense, imo.
For references, see http://lists.w3.org/Archives/Public/www-svg/2007Apr/0002.html