Related link: http://www.ftponline.com/weblogger/forum.aspx?ID=1&DATE=07/27/2004#185

I recently had a dialog with Jim Fawcette (CEO of Fawcette Technical Publishing) regarding the ‘A’ in SOA. The resulting discussion has been captured and written up by Jim as a Q&A on FTP’s web site.

The focus of the discussion is around Enterprise Service Bus (ESB), SOA, appservers, integration containers, Indigo, and JSR-208. The full discussion can be found here.

http://www.ftponline.com/weblogger/forum.aspx?ID=1&DATE=07/27/2004#185

Dave

I would love to hear your thoughts on this subject.

Related link: http://www.w3.org/TR/xbc-use-cases/

The first public Working Draft of the XML Binary Characterization Use Cases has been published. It’s not complete as a number of use cases still need to be written, and there is still some editorial work to be done on the existing ones, but it’s the first taste of what you’ll get from this working group, and your first chance to provide feedback.

As you may know, the task of the XML Binary Characterization WG (or XBC WG for friends and family) is to gather information that will help determine the nature of [the] use cases [for binary XML], characterizing the properties that XML provides as well as those that are required by the use cases, and establishing objective, shared measurements to help judge whether XML 1.x and alternate (binary) encodings provide the required properties.

This is to be a short-lived WG that will not produce Recommendations (but rather just WG Notes indicating its findings), so if you have feedback to provide you only have until circa the end of next March to give it. After that, either the WG will have failed in providing answers in time, or it will form an opinion on whether the W3C should produce a standard in that area or not. So give it now! Even if it’s just the first document in a series and it isn’t yet complete, there is already meat to comment on. We await your feedback with expectant impatience ;)

Do you think that the XBC WG is just a bunch of crack-smoking geeks? Or, irrespective of whether you think binary XML should exist, do you find their work useful?

Related link: http://www.xml.com/pub/a/2004/07/21/dive.html

Mark Pilgrim wrote an interesting piece on XML.com about how he considers that XML on the Web Has Failed. That’s a bold claim to make though, and while his arguments ferret out some real problems, they also carry serious flaws.

Starting with the flaws, he considers “strike 3″ to be that XML parsers are all buggy, broken, and liberal in what they accept rather than draconian. For this he refers to the XML specification, notably parts surrounding a bit that defines how encodings can be inferred when there is a high-level protocol carrying XML:

When multiple sources of information are available, their relative priority and the preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML.

Here, there are two things to stress. The first is that it says “should”, not must. The second is that this is part of Appendix F.2, which is non-normative anyway. Therefore, inferring rom that part of the specification, as Mark does, that XML parsers that don’t support RFC3023 are broken is wrong.

His “strike 2″ is that too many Web servers are misconfigured. Well, that’s sadly true, but it’s not really a failure of XML. In fact, it’s a big enough problem that some Web clients (most infamously IE) have included content “sniffing” code to try to deal with the issue, in turn making it far easier to never notice that servers are misconfigured in the first place. Yes it’s a problem, no it’s not something that XML can do much about. At best, it can try to derive practices that work around the problem.

“Strike 1″ is one are where he makes a good argument: RFC3023 is quite likely broken. Indeed, XML is very good at labelling the encoding that it’s using, the rules are precise and deterministic. Why oh why then would someone else, at another layer, want to add their own rules? File format and transport-level metadata should be as separate as they can possibly be, for there is little value and high cost in having incestuous relationships between the two.

So how to move forward? Well, I don’t claim to have the perfect answer, but it would appear to me that forbidding the usage of charset parameters on all XML Media Types is a good step forward. Processors will then be able to rely simply on the information contained in the XML documents and we’ll avoid clashes that buy us nothing and decrease interoperability. Content producers will then either produce well-formed XML or not, and it’ll be easy to fix. As a side note, I feel that Mark vastly overstates the value in using whichever encoding one wants. I’ve been sticking to UTF-8 and UTF-16 only for several years, and have been very happy using those for many languages. A second step could possibly be to stop kidding ourselves that XML is “just text” and drop the text/xml MIME type altogether, using only the application/* and image/* ones. That’ll teach those gung-ho transcoding proxies to behave.

Update! Right in the nick of time, it would seem that
Murata/Kohn/Lilley have produced an Internet Draft obsoleting 3023 :) The list of changes is as yet uncomplete, but one should already help: text/xml and text/xml-external-parsed-entity are deprecated. I highly recommend reading the text in section 3 that justifies this if you are interested in this topic.

Is XML on the Web really broken? Or has Mark produced a stimulating, but somewhat over-enthusiastic piece?

Related link: http://www.svg.org/blogs/graouts/archives/001361.html

Macromedia, cornered by the mobile industry quite decided to stick to standards, finally decides to make a magic PR turn-around, and get with the SVG program. But you wouldn’t think they’d give in without a dirty fight…

Macromedia’s Mobile and Devices product manager, Troy Evans, writes about the Flash Lite / SVG Tiny relationship, full with inaccuracies and blatant lies, a sorry state of affairs… Here’s a transcript of a journal entry of mine trying to set the record straight:

I am not going to comment on the pure marketing sides of this article, although there are a few things in there that made me raise my eyebrows. It’s really when it gets technical that I feel the need to speak out.

Troy Evans writes “In doing so, handsets can now support the basic needs of vector graphics as defined in the SVG-T profile, as well as the richer interactive multimedia feature set Flash Lite 1.1 provides“.

While he is right in pointing out that technically SVGT 1.1 does not offer a feature range as wide as Flash Lite, lack of programmatic (ie, through scripting an API) interactivity being the major difference, he is a little undermining when saying that SVGT only serves “the basic needs of vector graphics“. SVGT 1.1 supports 99% of the declarative animation features found in SVG Full. This goes beyond simple vector graphics.

Troy Evans then touches briefly (brief as Macromedia’s research of SVG I imagine) about differences between SVGT and Flash Lite: “SVG-T supports within its profile vector graphics, images, and text, but lacks the ability to add interactivity or audio without the use of additional auxiliary technologies such as JavaScript.”

Huh? As I said above, SVGT 1.1 does not allow for programmatic interactivity, but through the animation features available, a fair amount of declarative interactivity can be achieved in SVGT 1.1. You can change object’s colors, positions, geometrics and the likes in reposnse to mouse events. For a quick idea of what can be done today using SVGT 1.1 and its declarative interactivity features, you can go through the Beatware Mobile Designer (an excellent mobile SVG authoring tool) virtual tour. What we have there are things like buttons remotely triggering animations, buttons with animated rollover behaviors, navigation bars and popup menus. Not bad for a language that according to Macromedia “lacks the ability to add interactivity“. Point taken for the lack of audio in SVGT 1.1 though, this is only in SVGT 1.2.

So Troy Evans is on a roll, but he doesn’t stop there! “However, one of the problems with the SVG-T format is the many optional features that are inherent in the specification. So while our player conforms to the SVG-T standard, other implementations from other vendors may differ, causing differences in supported features across handsets and vendor implementations.”

Ok, the number one requirement for SVG Tiny was, and still is, no optional parts. There isn’t a single feature in SVG Tiny that is optional. Troy may be confusing SVG Basic and SVG Tiny here. I really can’t believe a company like Macromedia can say something like “we’re number one when it comes to SVG Tiny conformance”, where no one I know have been able to independently test their implementation. And of course we all know the tremendous history Macromedia has with regards to SVG, trying to undermine it since its very creation years ago. So, would anyone take Troy’s word and believe that Macromedia’s SVG Tiny implementation is more compliant than, say, BitFlash’s or ZOOMON’s, two companies involved in the standardization process at W3C for years who also have a number of shipping mobile phones on the market today with their implementation built-in? This is preposterous.

The fact is SVG Tiny is truly a specification with excellent interoperability. Ask a major carrier like Vodafone what they think about the level of SVGT interoperability. They’re making SVG Tiny one of the foundation technologies in their Vodafone live! client. Can you really believe that world’s largest carrier would commit to a technology without appropriate insurance that it is reliable? It’s only their flagship product after all…

It is becoming clearer every day, and we have evidence from the mobile phone market, that Flash Lite is getting its ass whooped by SVGT 1.1, even though SVGT 1.1 doesn’t have all of its features and doesn’t even have a multi-million dollar company pouring marketing resources into making it a success. And it’s only getting worse as SVGT 1.2 is getting closer and closer and should be a recommendation within six months. Feature-wise SVGT 1.2 goes beyond Flash Lite’s offerings, and with support from platforms like J2ME (through JSR-226) and Symbian (through Series 60 SE), you bet integration issues are pretty much figured out. And remember, SVGT is a standard, approved by W3C and 3GPP. No matter what play on words and rewrite of definitions Macromedia folks can come up with, Flash Lite is not standard.

In the end, Macromedia is only showing the world their ignorance of SVG, which doesn’t come as a big surprise considering their lack of SVG support, ever. As a friend of mine says: “you need to trust a company if you are putting their product into millions of devices. Macromedia show they are not worthy of that trust”. Realize!

Are Macromedia desperate enough to spread malignant lies? Or are they simply misinformed?

Related link: http://free-culture.cc/notes/