Like a stored table, the result of a relational query is flat, regular, and homogeneous. The result of an XML query, on the other hand, has none of these properties. For example, the result of the query “Find all the red things" may contain a cherry, a flag, and a stop sign, each with a different internal structure. In general, the result of an expression in an XML query may consist of a heterogeneous sequence of elements, attributes, and primitive values, all of mixed type. This set of objects might then serve as an intermediate result used in the processing of a higher-level expression. The heterogeneous nature of XML data conflicts with the SQL assumption that every expression inside a query returns an array of rows and columns. It also requires a query language to provide constructors that are capable of creating complex nested structures on the fly -- a facility that is not needed in a relational language.
--Don Chamberlin
Read the rest in XQuery from the Experts: Influences on the design of XQuery - WebReference.com-
I have learned that APIs can play into the hands of those who don't really want you to understand what is going on underneath, as that would threaten their control over your conceptual model of how the system works. I can think of numerous examples over the years where APIs have had this effect in the industry.
--Sean McGrath
Read the rest in ITworld.com - XML IN PRACTICE - APIs Considered Harmful
the benefits of binary XML over text XML are only significant in edge cases, and in most of those a custom, non-Infoset-based serialization would almost certainly be better. Having a completely different XML serialization adopted widely could significantly screw up the benefits a common format offers.
--Danny Ayers on the atom-syntax mailing list, Monday, 29 Dec 2003
The idea of escaping markup goes against the fundamental grain of XML. If this hack spreads to other vocabularies, we'll very quickly find ourselves mired in the same bugward-compatible tag soup from which we have struggled so hard to escape.
--Norm Walsh
Read the rest in XML.com: Escaped Markup Considered Harmful [Aug. 20, 2003]
In 1998, I don't think any of us anticipated the level of adoption (and hype) we've seen around SOAP-based technologies. It's now more than five years later and I can say confidently that SOAP itself is done. The WS-I Basic Profile cleaned up some of our ambiguities in SOAP/1.1 (the version of SOAP that is most widely deployed today) and the W3C finished the SOAP/1.2 specification, which gives the world a stable base to build upon going forward. The evolution of SOAP is no longer about SOAP itself but rather what people do with SOAP. Yes, the earliest application of SOAP was RPC (remote-procedure call). Going forward, RPC plays a role but isn't necessarily the primary way people will build SOAP-based systems.
--Don Box
Read the rest in Microsoft's Box Riffs on Life Inside The Empire
Frankly, all these hundreds of patents whose only *new* feature is that they use XML or HTML or XHTML or whatever to do things, should be considered junk. Just as you can't patent the mere substitution of plastic for wood in some application, you shouldn't be able to patent the mere use of XML or HTML in some well-known application. The intent of those who defined XML was to support an entire class of applications. Only if one can show that the specific use of XML is not anticipated in that class of applications should one be able to get a claim on a specific use. The current practice is simply a land-grab. It has nothing to do with originality or furthering any of the goals specified for patents in the US constitution.
--Bob Wyman on the xml-dev mailing list, Thursday, 18 Dec 2003
Putting QNames into your XML content is like using TCP packets as delimiters in an application protocol.
--Mark Nottingham
Read the rest in mnot’s Web log: QNames are Evil
Last time I checked (maybe 6 months ago), there were over 300 patents or patent applications with the word XML in the title. Think about that.... I personally have seen very, very little, that I think is new since 1994 or so, so almost every one of those 300 will have significant prior art. Prior art alone is *not* sufficient for have a patent deemed invalid though, and that is at least part of the problem.
--Gavin Thomas Nicol on the xml-dev mailing list, Wed, 17 Dec 2003
xs:duration is broken and should never have made it into the W3C XML Schema REC in the first place. Simple question; Is an xs:duration representing 3 months equivalent to an xs:duration representing 90 days?
--Dare Obasanjo on the xml-dev mailing list, Saturday, 28 Sep 2002
There are no security loopholes in XML, only in the software that you use to process it.
--Michael Kay on the xml-dev mailing list, Tuesday, 18 Nov 2003
The prevailing wisdom five or ten years ago about how distributed systems would be built in the future was CORBA, IIOP, object request brokers. The rave at the time was to make the world look like objects, in particular, to have a bunch of infrastructure that shrouds the fact that objects are distributed. The nirvana ideal was that you could just say Object obj = CreateMeAnObject(), and then call obj.ThisMethod(), obj.ThatMethod(), and you wouldn't know if that object was over in Thailand, right next door, or in the same process. The problem with that type of programming is: it works great in a single process; it works quite well across processes; it works fairly well in a small intranet; but then it completely sucks thereafter.
If you hide the fact that messages go across a network, and don't know when they go across, you end up with chatty conversations. And all of a sudden, the speed of light can become a big problem for you. You can't engage in a conversation with an object out in New York that goes, obj.LetMeGetX(), obj.LetMeGetY(), obj.LetMeGetZ(). No, you need to say, obj.LetMeGetXYAndZ(), and have everything come back in one chunk. But you can't really do that unless you actually make people understand that they are building a distributed application. In other words, you shouldn't try to pretend that a remote object is just a local object, because there is a difference. That's one thing that works so well about web services.
Moreover, web services run on existing infrastructure that we know scales. Web services that run over HTTP are just machine-to-machine communication over precisely the same infrastructure that we all use daily when we use browsers. And we know perfectly well how to scale that. If there's anything we know about scaling up, that's it. So why not leverage that? That's what web services do. Whereas, we know precious little about how to scale CORBA systems in a geo-scalable fashion. We just don't. There's just no knowledge about it, and I've never heard of anyone being particularly successful doing it.
--Anders Hejlsberg
Read the rest in Innapropriate Abstractions
experiments have shown that documents in a compressed XML file are usually significantly smaller than the Microsoft Word's native file format, a binary format that one might imagine would take less space. The reason relates to a fundamental of the Unix philosophy: Do one thing well. Creating a single tool to do the compression job well is more effective than ad-hoc compression on parts of the file, because the tool can look across all the data and exploit all repetition in the information.
--Eric S. Raymond
Read the rest in Data File Metaformats
XML is more like contractors who take care to ensure that the foundation and building are up to code and will last a long time for their homeowners, while Macromedia is a company that builds feature-filled homes quick without much concern for the building code and rents them out to whoever needs a house in a hurry...
--Simon St. Laurent
Read the rest in oreilly.com - - From the Editors List
Indeed the XML brand grows worryingly, but it is terribly important for the integrity of that brand that when someone says "this data is available as XML", that they provide unicode characters with angle brackets on demand.
--Tim Bray on the xml-dev mailing list, Thursday, 05 Dec 2002
The whole point of XML based interop is that you can send the data on the wire independent from the API. By defining interop on the API level, you are missing the point of using data instead of code to achieve information exchange and interoperability. Using an XML API over relational databases or ASN.1 is fine, but it only gives you the wrapper part of a mediator architecture that allows you to integrate information from different sources (which is basically just another way at looking at the loosely-coupled aspect).
--Michael Rys on the xml-dev mailing list, Tuesday, 18 Nov 2003
XML is just text. It is not a level lower than text, consisting of the bytes, or in another context the glyphs, which are rendered from particular encoding as the characters of that text. Nor is XML an abstract precursor to text, nor any abstraction of the syntax in which text is manifested. XML is text; a body of XML syntax is fundamentally a text (whatever else it might be agreed, or even misunderstood, to be).
--W. E. Perry on the XML DEV mailing list, Tuesday, 25 Nov 2003
Now you are dealing with so-called XML _datatypes_, which only exist in terms of applications layered on XML such as XML Schema or RDF. What I am saying is that _for XML_ any so-called datatype is just another piece of XML.
--Jonathan Borden on the xml-dev mailing list, Sunday, 23 Nov 2003
I've been waiting for Linux to become usable by the non-geek community for years, and though it's getting closer, it's nowhere near the Windows level yet (sounds cruel, but it's true.) Telling people to buy specific hardware because Linux supports it places the Linux community in with the Mac folks, not the Windows masses. Linux needs to run well on any system that could run Windows XP. Out of the box. Period. No excuses.
Because if I have a hard time getting this stuff to work, imagine how my mom would feel?
--James Turner
Read the rest in *LINUXWORLD SPECIAL* Is Linux Desktop-Ready Yet...or Not? (LinuxWorld)
one major value of XML to me (employee of XML DBMS vendor) is to avoid the necessity of separating the "text" from the "structured info." While XML DB's don't have the advanced fuzzy/baysean capabilities of high-end text DBs (yet!), they do have the ability to query for text matches IN THE CONTEXT OF the structure. Given a certain amount of predictability about the tagging of a resume, one could look for people with actual EXPERIENCE with some technology combination (Java on Linux, for example) rather than just "Java" and "Linux" mentioned somewhere near each other or whatever.
--Mike Champion on the xml-dev mailing list, Monday, 28 Oct 2002
the XML:DB API got a triple wammy of problems. It was intended to be database agnostic, language agnostic and also Java like. The DOM set the precedent, we definitely should have known better. :-)
Just removing the language agnostic bit would have helped a ton. At least it would have done away with the need to be expressible in IDL. I will definitely avoid ever trying to define another language agnostic API. It's just a bad idea that leads to a crappy result for all languages.
--Kimbro Staken
Read the rest in Inspirational Technology: The pain of over abstraction
Relational data is "flat" -- that is, organized in the form of a two-dimensional array of rows and columns. In contrast, XML data is "nested", and its depth of nesting can be irregular and unpredictable. Relational databases can represent nested data structures by using structured types or tables with foreign keys but it is difficult to search these structures for objects at an unknown depth of nesting. In XML, on the other hand, it is very natural to search for objects whose position in a document hierarchy is unknown. An example of such a query might be "Find all the red things", represented in the XPath language by the expression //*[@color = "Red"]. This query would be much more difficult to represent in a relational query language.
--Don Chamberlin
Read the rest in XQuery from the Experts: Influences on the design of XQuery - WebReference.com-
I have no time for Windows, no patience for rebooting and I lack that ability to forget the last 10 times it crashed on me. Most Windows people forget. Marc Fleury is an example of this, regaling me with "buy a real computer" (how Windows/Intel qualifies for any bravado as a real computer is beyond me). Marc says his Windows laptop never crashes; however, every time I've been at a JBoss related conference, his Windows laptop undergoes some reboot or crash.
My Mac is overall very stable. I only reboot it when I do something that I couldn't do on Linux and doesn't work very well on Windows... That is, rapidly plug in and disconnect strange projector devices. Windows would give me a sure Purple Screen of Death (they removed the BSoD by making it purple). Linux, well I'd spend days reconfiguring X.
--Andrew C. Oliver
Read the rest in Hacking Log 4.0: Phase II
we need to be very cautious about assuming that the world needs both a binary and text encoding -- people gripe about parse speed of XML as if it will be faster when it's binary, and I think this is incorrect from two perspectives -- first is that we have shown XML-oriented protocols to be faster than binary in many cases, and second because there is still tons of room for improvement in text parsing speeds (the fact that gen 1 of XML parsers is slow simply proves that they are gen 1 parsers, not that text is inherently slower than binary).
--Joshua Allen on the xml-dev mailing list, Tuesday, 18 Nov 2003
[X]HTML + [CSS] + [Javascript] rule the portable web app interface game today, as evidenced by, well, just about anybody's homepage. But we're still not happy with it. Why? One big reason for me: Rich interfaces are possible, but anything sufficiently advanced requires massive amounts of DHTML-fu. I've been there. Three weeks and a dozen hacks later, I've still got an application to write.
--Chris Wilper on the xml-dev mailing list, Tuesday, 4 Nov 2003
I'm sitting here in Seattle's airport. My flight is delayed. The plane is broken. A new one is getting flown in. But, it gives me some time to think about how people perceive brands and what can affect that perception. Particularly when it comes to Microsoft
What do you think when I say "Nordstroms?" I think great service. "Coca Cola?" Refreshing. "Nike?" I wanna be like Mike. Apple Innovative. "Levis" Cool. "Krispy Kreme" Hot and fresh.
Now, what do you think when I say "Microsoft?" Do you think "Monopolistic? Ruthless? Rapatious? Arrogant? Low quality? or Untrustworthy?" Many people do.
Come on, admit it. Microsoft doesn't have the best brand in the business. Why is that? Microsoft has earned that position in your mind through its behavior. I know that down in Silicon Valley I watched as Microsoft's economic power expanded and people became fearful. Heck, three years ago I was almost fired because I made a Microsoft employee mad at me
--Robert Scoble
Read the rest in The Scobleizer Weblog
When problems are encountered with an object stream, they're hard to correct because the format is binary. An XML document is human readable, and therefore easier for a user to examine and manipulate when problems arise. To serialize objects to an XML document, use the class java.beans.XMLEncoder; to read objects use the class java.beans.XMLDecoder.
One reason object streams are brittle is that they rely on the internal shaper of the class remaining unchanged between encoding and decoding. The XMLEncoder takes a completely different approach here: instead of storing a bitwise representation of the field values that make up an object's state, the XMLEncoder stores the steps necessary to create the object through its public API.
--Joe Winchester and Philip Milne, Java Developers Journal, June 2003, p. 28
PowerPoint is for sissies. All right, not for sissies, exactly, but it's being done to death. PowerPoint Makes Everything Really Important in a Telegraphic Way. That's Fine in Some Cases, But It Gets Tiring When It Happens Too Much. Besides, PowerPoint is the triumph of the quick "fact" over the art of argumentation. And a lecture is, or should be, a kind of argument. It's more, too -- a chance to observe a voice, a body, a brain, and a personality engaging an audience with similar interests. If you put your bulleted ideas up on slides, your audience will look at the slides, not at you. You'll also be teaching them that What You Have to Say Can Be Summarized in a Few Words. Can it?
--William Germano
Read the rest in The Chronicle: 11/28/2003: The Scholarly Lecture: How to Stand and Deliver
RSS, by design, is difficult to consume safely. The RSS specification allows for description elements to contain arbitrary entity-encoded HTML. While this is great for RSS publishers (who can just “throw stuff together” and make an RSS feed), it makes writing a safe and effective RSS consumer application exceedingly difficult. And now that RSS is moving into the mainstream, the design decisions that got it there are becoming more and more of a problem.
HTML is nasty. Arbitrary HTML can carry nasty payloads: scripts, ActiveX objects, remote image “web bugs”, and arbitrary CSS styles that (as you saw with my platypus prank) can take over the entire screen.
--Mark Pilgrim
Read the rest in New York Times: NYT HomePage
In a relational database, the rows of a table are not considered to have an ordering other than the orderings that can be derived from their values. XML documents, on the other hand, have an intrinsic order that can be important to their meaning and cannot be derived from data values.
--Don Chamberlin
Read the rest in XQuery from the Experts: Influences on the design of XQuery - WebReference.com-
In dusting off my presentation for XML 2003 I have a slide that explains why we needed XML and the problems with SGML. This slide is very old (at least 6 years):
SGML Problems
- High initial investment
- Complexity
- Too many options/features
- Vendors supported a subset of features
- Applications weren't portable because of various feature sets
- Lack of intuitive end-user software
- Fear of "pointy brackets" (<>)
As I read this list and after my experiences with XML Schema - I ask myself where are we? About the only thing I think we can take off of the list above is the "Fear of 'pointy brackets'" and that is a result of HTML, not XML.
--Betty Harvey on the xml-dev mailing list, Tuesday, 25 Nov 2003
The only meaningful way to draw a line separating XML from the abstract syntax camp is to insist that--at the level of the parseable document--there is no equivalence except character-by-character lexical equivalence. That is a fundamental distinction, and one worth insisting upon for the extraordinarily useful consequences it delivers. Now, granted, the simplest of compliant XML 1.0 parsers will make no distinction between single and double quotes delimiting attribute values nor between various manifestations of whitespace, but accepting such abstract equivalence is the price of compromise necessary to have an agreed XML 1.0 Recommendation implementable in a parser. Choose stricter premises and you will find it necessary to implement something like Simon St.Laurent's Ripper. However, for the benefits of a global XML community and the bounty of general-purpose tools it produces, many of us have accepted those particular assertions of abstract equivalences which are incorporated in the XML 1.0 Recommendation. We accept them as specific, enumerated exceptions to an otherwise prevailing rule, and as identified exceptions they in fact confirm the existence of that rule in their absence.
--W. E. Perry on the XML DEV mailing list, Monday, 24 Nov 2003
XML is based on free and open standards, so every time I see that phrase MSXML, I get a little nervous.
--Charles Goldfarb, October 23, 2001 (XML Journal 2-12, p. 34)
Is the message that is transmitted *what is transmitted* or rather *something else* that is encoded in the message. If you are primarily looking from the vantage point of an application which communicates with another application *as if via RPC*, then the interface is primary and the bits on the wire are secondary. On the other hand if you are sending a document from one place to the other, then the document is primary. XML was not designed to be the "perfect" RPC protocol. XML remains a great way to "encode" documents -- saying this seems like a tautology -- because to a large extent the XML *is* the document.
--Jonathan Borden on the xml-dev mailing list, Sunday, 23 Nov 2003
most people develop binary formats because they're simpler than XML, and they'd rather be getting on with writing their application than bothering with DTDs and SAX and DOM and stuff, in my experience. The only reason to be convered with XML goo is if you have an overriding concern regarding 'being able to view and edit the files in a text editor'!
--Alaric B Snell on the xml-dev mailing list, Saturday, 22 Nov 2003
The hierarchical nature of XAML is one reason why a markup language makes more sense than programming code for defining a visual interface. The markup can mimic the hierarchy with nesting and indentation. In fact, when Windows 1.0 was first introduced in 1985, programmers used a text resource script to define the hierarchical structure of their menus and dialog boxes. At the time, the hierarchy only went one level deep, but it was a start. An XAML file is just the resource script.
--Charles Petzold
Read the rest in Code Name Avalon: Create Real Apps Using New Code and Markup Model -- MSDN Magazine, January 2004
I fear that splitting the interop story of XML into a textual and Infoset-based/binary representation, we are going to get the "divide and conquer" effect that in the end will make XML just another ASN.1: a niche model that does not deliver the interop it promises and we will be back to lock-in.
--Michael Rys on the xml-dev mailing list, Tuesday, 18 Nov 2003
for any new protocols, XML should be considered to be the default encoding. The only exceptions, and there are always exceptions, would be applications like sending telemetry from Mars where every bit counts... (But, even in such cases, it would still be useful to have the XML support if only to assist in debugging during development...)
--Bob Wyman on the xml-dev mailing list, Wed, 19 Nov 2003
XML has succeeded in large part because it is text and because it is perceived as "the obvious choice" to many people. The world was a lot different before XML came around, when people had to choose between a dizzying array of binary and text syntaxes (including ASN.1). Anyone who tries to complicate and fragment this serendipitous development is, IMO, insane.
--Joshua Allen on the xml-dev mailing list, Tuesday, 18 Nov 2003
I have long held out hope that the big lessons of HTTP would be
(a) keep it readable (design time)
(b) maximise statelessness (design time)
then
(c) scale it horizontally (deploy time)I'm on the verge of concluding that this message is a stillborn. A real tragedy given the amazing scaleability of the Web. If ever there way an example of how to "optimize" an IT system the Web is it :-)
So why doesn't the message get through?
Perhaps because it is not obvious where the $$$ are in a "keep it simple, keep it readable, scale it horizontally on the cheap." view
--Sean McGrath on the xml-dev mailing list, Monday, 22 Sep 2003
Unless the world goes to semantics free, invent your own elements, XML, HTML and maybe XHTML, will be the main users of CSS for a long time to come. Both semantics free XML and presentational HTML are bad things, in my view.
--David Woolley on the www-style mailing list, Monday, 20 Oct 2003
The evolution of the web interface for the humans away from the browser and into other parts of the operating system has been predicted on this list and elsewhere from some time now. Browsers are a kind of vestigial organ from the early days of hypertext that reemerged for the WWW. They aren't required, but they made a great HTML handler and a nice sandbox for newcomers to hypermedia to learn and develop the technologies over the Internet. They aren't necessary; just cheap and convenient. Like XML.
--Claude L Bullard on the xml-dev mailing list, Tuesday, 28 Oct 2003
It is amusing to me that at the time of its inception the impetus for the creation of "SGML for the Web" aka XML was to throw off the shackles of HTML and the notion of one-size-fits-all markup vocabularies. Over time people have gotten this twisted belief that unless an XML technology is rubber stamped by some brahmins in some working group or technical committee then it isn't worthwhile. XML is about freedom not serfdom, the sooner the XML community and the software industry as a whole begin to realize this fundamental truth about XML the better for us all in the long run.
--Dare Obasanjo on the xml-dev mailing list, Monday, 3 Nov 2003
Overall, there's a real dilemma for the Powers that Be: On one hand, "design by committee" is not a great strategy, at least <subtleDig target="XQuery"> if you want a Recommendation within 5 years of the Workshop. </subtleDig> :-) Coming up with a solid proposal by some back channel communications can improve both time to complete and quality. On the other hand, they just can't help themselves from getting wrapped up in Big Power Politics whenever some obvious need (like SOAP extensions for reliable messaging across diverse networks) comes along.
--Mike Champion on the xml-dev mailing list, Tuesday, 7 Oct 2003
The systems that have succeeded at scale have made simple implementation the core virTuesday, up the stack from Ethernet over Token Ring to the web over gopher and WAIS. The most widely adopted digital descriptor in history, the URL, regards semantics as a side conversation between consenting adults, and makes no requirements in this regard whatsoever: sports.yahoo.com/nfl/ is a valid URL, but so is 12.0.0.1/ftrjjk.ppq. The fact that a URL itself doesn't have to mean anything is essential -- the web succeeded in part because it does not try to make any assertions about the meaning of the documents it contained, only about their location.
--Clay Shirky on the nec mailing list, Friday, 7 Nov 2003
Hypertext wasn't invented with the Web. Hypertext had been around as a concept for 20 or 30 years. The earliest popular description of this was this book called Computer Lib, a written a long time ago by Ted Nelson. That book really was about what you could do with hypertext, and he had this project called project Xanadu that was trying to do that. But they went off and did the usual computer science thing, which is to try to solve all the hard problems and make it perfect.
One of the hard problems is exactly what you were just asking about concerning distributed systems. You've got a reference to a remote resource. What happens if that remote resource moves? Should you keep the backtracking information? How do you keep the backtracking information? Solving that problem is really, really, really hard. Lots of people went running at that brick wall over, and over, and over again, trying to find a way to make these large scale distributed references really work. In the computer science academic world, it was generally considered that an internet link just wasn't of any value unless it could handle resource moving and renaming and issues like that.
In some sense, the brilliant thing that Tim Berners-Lee did was simply to say, "I don't care." For 20 years people had been failing to solve these problems in any large-scale way. Berners-Lee decided to just do the simple obvious thing that solves the problem he needed, namely, getting ahold of a resource. And that's actually an easy problem. Coming up with those names, URLs, is a relatively straightforward thing. He did that, and that enabled a lot of what the Web is today. But the Web has all these problems. What happens if a Web page moves or gets deleted? That is exactly the problem of maintaining or managing the configuration of any large scale distributed system. On the one hand, the URL design has made the Web somewhat fragile. Broken links are all over the place. On the other hand, if they had tried to really solve that problem, the Web never would have happened, because the problem is just too hard.
--James Gosling
Read the rest in Visualizing Complexity
I think there are a lot of developers out there doing silly things with XML, especially in web services. But, I do know that the most of developers I've come across in my work with XML much prefer working with Plain Old XML mapped onto Plain Old Objects. Anything else is treated as gorp that somebody or some tool is imposing on them, supposedly for their own good.
--Bill de hóra on the xml-dev mailing list, Sunday, 09 Nov 2003
the new features in XML 1.1 and Namespaces 1.1 are of very marginal value compared to the costs created by the discontinuity, for vendors and users alike.
--Michael Kay on the xml-dev mailing list, Monday, 21 Oct 2002
quoting the W3C's own rules to it seems to accomplish nothing whatsoever. So far as I can tell they treat the Process document as W3C Recommendations are supposed to be read: as guidelines, not capital S Standards.
I'm not sure what to make of the many last-minute changes to W3C XML Schema, or of the XHTML WG's penchant for skipping CR, or of poisonous namespace features added at the very end of the XPointer process. It happens. The W3C doesn't appear to care institutionally.
--Simon St.Laurent on the xml-dev mailing list, Wed, 22 Oct 2003
I think Web services is probably the best level of agreed-upon interoperability we've had. There's only two stacks now--.Net and Java. The world should have two, for competitive reasons. To the extent that we coexist so I can't tell what's on the other side of the wire, that's a beautiful state to be in.
--Greg Papadopoulos, Chief Technology Officer, Sun Microsystems
Read the rest in On the hot seat at Sun |CNET.com
XML probably couldn't be done anymore at W3C. The reason XML was so successful is that nobody noticed--we came in low, fast and under the radar, and it was already finished by the time the big vendors noticed it. Now, any time there's a new initiative around XML, there are instantly 75 vendors who want to go on the working group.
--Tim Bray
Read the rest in Taking XML's measure |CNET.com
Companies interested in doing the WS-Thing would do well to limit the investment to HTTP, XML, WSDL, and SOAP (in that order), steer clear of /WS-.*/ for a while and concentrate on what matters: the *services*.
Take web data-mining. Web scraping is alive and brittle in 2003. Not because of the adoption of or completion of UDDI, WS BPEL, WS-CAF, WSDM, WSDM, WSIA, WSRP, WSRM, WS-Security (or lack thereof). But for the simple reason that web-based data providers are still thinking only of one user-agent. That's where the change needs to happen.
--Chris Wilper on the xml-dev mailing list, Tuesday, 7 Oct 2003
If we could go back in time and I were appointed Infallible Grand Dictator of XML, I would not have allowed entities in the first place (though I might allow named character references of some kind). Realistically, though, some people do like entities quite a bit, so it's unlikely that they would have been dropped even if we had known then what we know now.
--David Megginson on the xml-dev mailing list, Tuesday, 21 Oct 2003
In general it's a bad idea to have user-visible content in attributes, because you can't put markup inside attributes. Consider (for example) needing something like
Calculate d<sup>2</sup>:
or a possible need to mix right-to-left and left-to-right scripts with markup to differentiate source languages.
--Liam Quin on the xml-dev mailing list, Tuesday, 28 Oct 2003
Something that has been only slightly alluded to in this (and many other) "why use XML" discussions is the leverage the tool set brings you. If the there is one blessing that the adoption of XML has brought to the IT industry it is the institutionalization of best practices for parsing, tree building and traversal and other common CS algorithms. OO reuse is much easier when you have syntactic reuse.
--Peter Hunsberger on the xml-dev mailing list, Wed, 29 Oct 2003
Microsoft wants to take over the internet by simply turning Windows Longhorn itself into a browser that use its own next-gen markup languages that go way beyond the W3C standards.
--Gerald Bauer on the xml-dev mailing list, Tuesday, 28 Oct 2003
For thousands of years, philosophers and scientists have attempted to explain the cosmos in terms of dual opposing but coexistent principles: good and evil, yin and yang, matter and energy, mind and body, waves and particles, and, of course, programming code and markup languages.
Programming and markup currently coexist in an uneasy truce. In theory, programming languages can do anything the computer is capable of, but they're often clunky for the job of laying out text, images, and controls in a simple visual interface. Markup is great for defining highly textured pages of text and images that adapt to different screen sizes and environments, but is hopelessly inept when it comes time to interact with the user in any nontrivial way.
In creating a new programming interface for building Windows®-based client applications, the developers at Microsoft have decided not to deny this dualism, but to embrace and celebrate it. They have created an environment in which programming and markup boldly and intricately mesh in mutually supporting roles. The result—the presentation subsystem code-named "Avalon"—may well be the greatest experiment in synergistic duality since Adam and Eve. Vive la différence!
--Charles Petzold
Read the rest in Code Name Avalon: Create Real Apps Using New Code and Markup Model -- MSDN Magazine, January 2004
it would be incorrect to say that data model is more important than syntax (for example, it is wrong to say that binary XML is equivalent to text XML "because they both just serve as serialization for the data model, which is primal"). In other words, syntax *is* primal, but that doesn't mean data model is unimportant -- data model is subordinate to syntax, but it is very nice gravy.
--Joshua Allen on the www-tag, Friday, 24 Oct 2003
XInclude is a wrong-size-fits-nothing kind of thing. Other specs that need XInclude-like functionality often need something with _slightly_ different semantics, and end up specifying it themselves instead of reusing XInclude (<xsl:import>, for instance).
--Joe English on the xml-dev mailing list, Friday, 09 May 2003
The TAG wars were a feature, not a bug. They contributed to an incredible evolution in html and browser technology
--David Orchard on the www-tag mailing list, Wed, 22 Oct 2003
I think Web Architecture has a preference for error behaviour that encourages folks to Do The Right Thing... a 404 error message is useful because it can say "contact the author of the _referring page_" and such. XML halt-and-catch-fire was useful/necessary to make broken XML docs sufficiently painful to consumers that they'd contact the producer and get it fixed rather than just tolerating it.
--Dan Connolly on the xml-dev mailing list, Tuesday, 21 Oct 2003
It is not really possible to implement CSS with a true tag soup browser, as CSS requires a well defined parse tree. (On that basis, I believe that NS4 is a tag soup browser with CSS bolted on and IE is a structured document browser with extensive error recovery logic to make it handle pages authored for tag soup browsers without complaint. This is based on the way they handle CSS (and other things like the way they handle validly and invalidly omitted tags).) Both encourage tag soup coding styles, and I think it may prove commercially very difficult for mainstream XML browsers to reject not-well-formed code as well.
--David Woolley on the www-style mailing list, Monday, 20 Oct 2003
Microsoft's biggest enemy is themselves. They do things that make people very upset and engenders a lot of resentment.
--Mike Silver, Gartner Group
Read the rest in Linux took on Microsoft, and won big in Munich Victory could be a huge step in climb by up-and-comer
Debating the pros and cons of XML namespaces is like arguing about whether the internal combustion engine is a good idea. The world has moved on.
--Dare Obasanjo on the xml-dev mailing list, Tuesday, 22 Jul 2003
For me, the problem with RDF is the demands it places on me for keeping track of the structures described. Invariably, when I look at information stored in RDF (or a Topic Map) in a graphical form, the connections make sense, the overall structure or lack thereof is very clear. When I look at the same information in its raw RDF document form, I start to mutter about people who are too damn smart creating models which are suitable only for computers and people who can think like computers.
--Simon St.Laurent on the xml-dev mailing list, Sunday, 17 Nov 2002
I learned from watching the DOM WG debate whether HTML in a browsers is "really" a tree or "really" lists embedded in lists that it is more or less impossible to persuade anyone who strongly believes in the opposite point of view. That's why the W3C DOM has both tree-traversal methods and list indexing methods; it would be logically complete with one or the other, but to choose one or the other would create winners and losers, which is bad politics in the standards world.
--Mike Champion on the XML Dev mailing list, Saturday, 01 Mar 2003
Any Windows user who goes on using Explorer after he or she learns that Mozilla is available is a masochist who should seek immediate psychiatric help
--Robin 'Roblimo' Miller
Read the rest in NewsForge: The Online Newspaper of Record for Linux and Open Source
Apple's experiment is a hopeful sign, but it will only be effective if independent labels are allowed compete directly with the major labels. When some are able to offer songs at 15 cents a copy to compete with songs offered at 99 cents a copy, then we will have the kind of competition that could explode the Internet as a medium for distribution.
--Lawrence Lessig
Read the rest in Online NewsHour: Forum -- Copyright Conundrum
We have requests to support things such as the Japanese calendar or complex numbers in DSDL and I think we'd better find a way to let people define what they need rather than attempting to be "universal" and define all the possible datatypes.
--Eric van der Vlist on the xml-dev mailing list, Friday, 10 Oct 2003
The SOAP Rec is unambiguous, to be a SOAP binding you must preserve the Infoset, which means you must preserve the characters even if in non-canonical form (especially since SOAP doesn't even know about types!) If it's an integer, you must preserve leading zeros, and if it's base64Binary you must preserve whitespace, etc.
--Noah Mendelsohn on the xml-dist-app mailing list, Thursday, 9 Oct 2003
On a lot of machines, "text" and "binary" files are the exact same thing, only the text files hold all their data in a form which a simple interactive editor like "vi" can manipulate. "Binary" usually just means that the data is packed in nice and tight, and nobody would even consider messing with it by hand. They'd use a library which has some functions built into it to manipulate the data in semantically self-consistent ways. For instance, many "binary" files have checksums in them. If you change a bit anywhere, you need to update the checksum. Many formats have ways of mangling them completely: if your file is block-coded with block headers describing the content and length of each block, one insert within a block will kill the file. Unless you update the block length, the file has become meaningless. If a file describes matrix-like data, the matrix dimensions must be consistent. You insert or delete an entry, and the matrix rows are skewed. The file is invalid. Many files have complex, built-in self consistency which must be respected by any tool which manipulates them.
--Graydon Hoare
Read the rest in grieve with me, blue master chickenz
in the WWW world, conformance to SGML has never been much more than lip service. Nothing that the WWW related specifications say about SGML should be taken at face value. It suffices to say that none of the common browsers ever supported HTML as defined as an SGML application, e.g. supporting tag minimization.
--Jukka K. Korpela on the www-style mailing list, Thursday, 9 Oct 2003
Garbage in is easily detected. One the more intimidating things about working with XML is that everybody can read it and you can't waffle your way out of problems half as easily :) I've had business owners point out problems with data in XML because they were standing behind me and noticed something. I have never seen a business owner do that with binary formats even with said (not so little) viewing tools, and that includes rdbmses. I have a business user who is happy (nay, wants) to have the raw XML emailed, until will build out reporting during a future iteration. XML is a 'visually tactile' technology, which I think is important.
--Bill de hòra on the xml-dev mailing list, Saturday, 20 Sep 2003
Google and Amazon did some cool stuff. XMethods has nice listing of (mostly "toy") public web services. But in large part, the useful "services" on the web are still HTML-only.
--Chris Wilper on the xml-dev mailing list, Tuesday, 7 Oct 2003
I prefer parsing XML documents into objects that conceptually represent a schema's data model, because the code is more explicit. But that approach only makes sense if a schema exists and you can require that all documents strictly adhere to that schema. It isn't appropriate in all situations.
--Bill Venners
Read the rest in The Human Side of XML
Standards processes don't do well in dealing with new technologies, so I disagree that being ahead of the market is a good thing. The standards process works best when you've got a problem that's already been solved, and we have a consensus on what the right way to go is, and you just need to write down the rules.
That's totally what XML was. There had been 15 years of SGML, so there was a really good set of knowledge as to how markup and text should work. And the Web had been around for five years, so we knew how URLs (Uniform Resource Locators) worked, and Unicode had been around, so we knew how to do internationalization. XML just took those solved problems, packaged them up neatly and got consensus on it all.
--Tim Bray
Read the rest in Taking XML's measure |CNET.com
XML operates in an abstract universe substantively divorced from the thought patterns of the vast majority of human beings. For many users of computer systems XML is, quite bluntly, bloody difficult. To many, XML is incomprehensible.
--Andrew Watt on the xml-dev mailing list, Wed, 1 Oct 2003
When people ask me to list the advantages of markup languages like XML, this is usually one of the first things that comes up -- XML is extremely Sneakernet compatible, so that you can burn all of your data onto a CD or floppy, carry it 200 meters, and then load it into the secure computer with no loss. Try that with CORBA or DCOM.
--David Megginson on the xml-dev mailing list, Friday, 3 Oct 2003
almost all users are now using a browser that is not going to be upgraded, short of replacing their operating system.
--John Cowan on the Unicode mailing list, Friday, 26 Sep 2003
Beware programmers trying to treat XML like a set of database records. Many such programmers blame XML when then cannot load an *entire* record set into memory. The same programmers would never contemplate loading an entire database into memory. Approaching XML processing the wrong way (its just a database, right?) can lead to non-sequiters like binary XML.
--Sean McGrath on the xml-dev mailing list, Thursday, 25 Sep 2003
It's no secret that the advantages of upgrading operating systems or application software has diminished quite significantly over the last few years. If you look back over history, there were great advantages from one release to another. You just don't get that anymore. You just don't get the bang for your buck switching from 2000 to XP.
--Toni Duboise
Read the rest in Microsoft feeling Office heat? | CNET News.com
Television is run by people who make their living telling other people what to watch and when, while cramming in more and more ads to pay for it all. Plug in a device that short-circuits the system and they're in trouble. Network execs don't get paid millions to admit their best years are behind them. But late at night, when they're sitting in their Dolby surround-sound home theaters flipping past Letterman and Leno and Nightline to channels 252 and 286 and beyond, or checking their TiVos to see what they missed during dinner, they know.
--Frank Rose
Read the rest in Wired 11.10: The Fast-Forward, On-Demand, Network-Smashing Future of Television
Television is run by people who make their living telling other people what to watch and when, while cramming in more and more ads to pay for it all. Plug in a device that short-circuits the system and they're in trouble. Network execs don't get paid millions to admit their best years are behind them. But late at night, when they're sitting in their Dolby surround-sound home theaters flipping past Letterman and Leno and Nightline to channels 252 and 286 and beyond, or checking their TiVos to see what they missed during dinner, they know.
--Frank Rose
Read the rest in Wired 11.10: The Fast-Forward, On-Demand, Network-Smashing Future of Television
except for trivial, academic cases RDF Schema and OWL do not have the robustness to capture the dynamically changing nature of real-world semantics. To do so, we must go beyond these ontology languages.
--Roger L. Costello on the xml-dev mailing list, Sunday, 28 Sep 2003
XHTML, although it is technically an XML application, is essentially HTML with a tighter, more consistent set of rules. If you know HTML, you can learn XHTML in fifteen minutes -- and check your work for free via the W3C or WDG online validation services. Using these services helps you remember the rules and avoid many browser problems. Some popular browsers don't support the proper XHTML MIME type and for that reason some standards geeks won't use XHTML yet. But the benefits of automated workflow and seamless interaction with XML-based publishing tools, syndication and description formats and Web services to my mind far outweigh that issue.
--Jeffrey Zeldman
Read the rest in Meet The Makers - Creative people in a technical world.
One of the most important characteristics of XML, as compared with many, many competing formats for the storage and/or transmission of data is that it is textual (in the sense of being conceptually a sequence of characters, and represented on the wire -- at least so far -- as such). Since much of the XML which I care about is also a digital representation of texts (in the sense of being natural-language utterances with a certain degree of intra-document linguistic and thematic cohesion), it troubles me to think that labeling XML as text buys us nothing of value.
--C. M. Sperberg-McQueen on the www-tag mailing list, 17 Sep 2003
Good browsers support GIF, JPEG and PNG without any problem: if the infrastructure allows plurality, then having a few different mainstream alternatives with different tradeoffs gives richness. This is where, most notably, W3C XML Schemas fails: it does not provide a mechanism to allow parts of it that fail to be readily improved or swapped out. People are stuck with the whole thing.
--Rick Jelliffe on the XML Dev mailing list, Thursday, 25 Sep 2003
People seem eager to forget how the world was before XML 1.0. Too-clever people can argue all day that "XML 1.0 is qualitatively not much better than CSV". But this misses the point. XML 1.0 has been able to achieve a degree of ubiquity and platform support that makes it "the obvious choice" for people who previously had to choose between various CSV, ASN.1, etc. The impact of that contribution is hard to overestimate. Why people are so hasty to go back to a world of multiple, incompatible encoding techniques is beyond me. For God's sake lets be happy that we have XML 1.0 and progress to the new millennium where we get to argue about incompatible schemas instead.
--Joshua Allen on the xml-dev mailing list, Wed, 24 Sep 2003
The number of complaints W3C gets about spam just because it's written in HTML with a <!DOCTYPE...> pointing to us... well, it doesn't make me feel like more end users should get to see the textual codes underneath the hood.
--Dan Connolly on the www-tag mailing list, Thursday, 18 Sep 2003
The sad fact of the matter is that the majority of the software development community suffer from premature optimization tendencies. Its like an illness we fight all our lives. I'm still fighting it but at least now, after twenty years, I realize I'm ill :-)
Vendors know all about this predisposition to myopic optimization, so they give the market what the market wants (as opposed to what the market actually needs) which is stuff that feeds the urge to optimize. Phrases like "tight integration" or "industrial strength" are used to deflect attention from what is really going on - more often than not - dubious engineering. It amounts to the same thing - feed the craving for optimization - however ill conceived it might be.
--Sean McGrath on the xml-dev mailing list, Monday, 22 Sep 2003
In my experience, actual XML parsing generally takes so little time in a real-world project that optimizing it to zero would still bring no noticeable gain. The only exception would be something dealing with a constant, fat stream of XML data in real time (news feeds are too low-volume to qualify).
--David Megginson on the XML Dev mailing list, Sunday, 21 Sep 2003
Find a customer and imagine which you think they want to hear- "yes its slower but it'll be up in 12 weeks, cheap and cheerful, and anybody in oppers can read what's coming in off the wire", or "yes it blazes but it'll take six months cost more, and no, oppers won't be able to understand anything". Yes I do draw a direct correlation with text wire formats over internet protocols with cost-effective high relevancy integrations shipped earlier. Call me biased, but I honestly don't know how anything got done at all in middleware before XML and HTTP came along.
--Bill de hòra on the xml-dev mailing list, Saturday, 20 Sep 2003
XML (well, SGML) was invented to be a convenient way for humans to "mark up" text, interactively, so it could be later searched, formatted, indexed, referenced, and hyperlinked by a computer. this is a good goal, because plain text is conventionally quite difficult to process by a computer. computers don't have any of the brains that we do, and can't extract "meaning" out of text. it's a hard problem. decades of research, little real progress. so for plain text, SGML was a good idea (badly implemented tho). XML fixed the bad implementation aspect, but otherwise its goal was mostly the same.
The XML standardization process, however, took place during this period of very rapid growth of the internet (still underway), and as a result it really had the web as a backdrop to all the discussion about text. And the web really hilighted something people had sort of known for a long time but not had the guts to mention, which is that proprietary storage and transmission formats really suck. You can't interoperate with someone serving up a proprietary standard unless you buy their product, which is the whole idea, but it sort of feels like blackmail when you know there are free standards kicking around. It feels like someone trying to put a tax on your communications, which is really crappy.
--Graydon Hoare
Read the rest in grieve with me, blue master chickenz
It is a sign of the maturing and vitality of XML applications and the expertise of its users that books are starting to appear about advanced extensions to XML, or about applications built atop it. So, for example, some have written about XLink and XQuery. But those are very specialised extensions. By contrast, Harold has put together an advanced overview of ALL XML.
--Dr. Wes Boudville
Read the rest in Barnes & Noble.com - Effective XML: 50 Specific Ways to Improve Your XML
If I own a URI for my car and I assert my car is Blue, that doesn't make it true. And if eleven other people assert that it's Green, the fact that they're other people doesn't make their assertions false.
--Norm Walsh
Read the rest in IRC log of tagmem on 2003-08-18
Is it true to say that the size of "http://www.ibiblio.org/wm/paint/auth/vinci/joconde/joconde.jpg" is 743x1155 pixels, or is it true to say that it is 77x53 cm? It can't be both.
--John Cowan on xml-dev mailing list, Thursday, 24 Jul 2003
XML is about syntax and nothing else. People who think otherwise have been misled by the XML hype of yesteryear.
--Dare Obasanjo on the xml-dev mailing list, Tuesday, 12 Aug 2003
BitPass' predecessors failed for a variety of reasons and of course "poor implementation" was among them. Efforts like the ones Shirky mentions were plagued with problems: Elaborate and intrusive sign-up forms, flaky business models, mandatory plug-ins, blood-sucking hook-ups to bank accounts, vendor start-up fees, greedy profit splits, etc. Some even claimed to offer "micropayments" while refusing to support transactions below 99¢.
Another factor contributing to micropayments’ dismal first round was the simple fact that until very recently, few users were willing to pay for content while they still felt that they were paying with their time. Without broadband, the climate for paid content was hardly hospitable. Similarly, users who had just brushed away the styrofoam packing from their first home computer (and there were a lot of them in the '90s) were still factoring in the cost of that initial investment. Selling premium content to those users was as futile as selling pay channels to TV owners in 1952.
Shirky’s "epochal change" is real enough. Free content is here to stay, file-sharing is here to stay, and any attempt to completely wipe out either is doomed to failure (as it should be). But that in no way precludes the co-existence of markets based on the desires of willing sellers and willing buyers. To proclaim without a hint of doubt that such a market will never exist for low cost digital content contradicts everything we know about the Web’s inexhaustible capacity for variety and adaptation.
--Scott McCloud
Read the rest in Misunderstanding Micropayments - Scott McCloud
People want to believe in things like micropayments because without a magic bullet to believe in, they would be left with the uncomfortable conclusion that what seems to be happening -- free content is growing in both amount and quality -- is what's actually happening.
The economics of content creation are in fact fairly simple. The two critical questions are "Does the support come from the reader, or from an advertiser, patron, or the creator?" and "Is the support mandatory or voluntary?"
The internet adds no new possibilities. Instead, it simply shifts both answers strongly to the right. It makes all user-supported schemes harder, and all subsidized schemes easier. It likewise makes collecting fees harder, and soliciting donations easier. And these effects are multiplicative. The internet makes collecting mandatory user fees much harder, and makes voluntarily subsidy much easier.
Weblogs, in particular, represent a huge victory for voluntarily subsidized content. The weblog world is driven by a million creative people, driven to get the word out, willing to donate their work, and unhampered by the costs of xeroxing, ink, or postage. Given the choice of fame vs fortune, many people will prefer a large audience and no user fees to a small audience and tiny user fees. This is not to say that creators cannot be paid for their work, merely that mandatory user fees are far less effective than voluntary donations, sponsorship, or advertising.
Because information is hard to value in advance, for-fee content will almost invariably be sold on a subscription basis, rather than per piece, to smooth out the variability in value. Individual bits of content that are even moderately close in quality to what is available free, but wrapped in the mental transaction costs of micropayments, are doomed to be both obscure and unprofitable.
--Clay Shirky
Read the rest in Shirky: Fame vs Fortune: Micropayments and Free Content
<?xml version="1.0" standalone="yes"?><sizematters>I have no problem reading the small XML documents that I have for each HTML page on my web site. They are flat XML documents with a dozen or so elements for the title, subtitle, author, and so on. I edit those files by hand with vi mostly, and it works great. On the other hand, I tend to get lost in Ant files. When I look up how to do something with Ant, the syntax often seems hairy and difficult. XML doesn't seem as natural to me as a traditional context free grammar. I think people sometimes use XML in places where a traditional context free grammar would be better.</sizematters>
--Bill Venners
Read the rest in The Human Side of XML
Choice, to most users, is the ability to choose any program they wish, and have it install and run seamlessly, without affecting any other application already installed; without requiring them to know which GUI they're running (or even that they're running a GUI); without altering path statements; without editing configuration files; without facing a command prompt; and without having to compile any source code; create any makefiles, or any other programming task that only developers are fond of.
It's extremely important for the open source community to be responsive not only to users' freedom to choose, but also to users' freedom not to have to choose. They don't care that they can't see or change the source code to their current programs. They don't care that they don't actually own the software, as long as they only have to pay for it once. They don't care that most of their software comes from a single source. In short, they don't care about the fundamental issues behind open source software at all. But they do care about price, quality, availability, security, simplicity, and interoperability. Supply these, and open source will be the software choice.
So far, the open source community has been highly sensitive to the needs of power users, hobbyists, and centralized IT departments, but highly insensitive to the needs of average, technically (and sometimes literally) illiterate users. Many people will argue that the public should be educated to value software choice and to see Microsoft's impositions and removal of choice for what it is. But it is a grave mistake to stake Linux' future on the hope that millions of people will be inspired to software activism, that they will take the ideological high road when all they want is to buy a piece of software that works with a piece of electronics.
--A. Russell Jones
Read the rest in Linux vs. Windows: Choice vs. Usability
In my experience it's a serious source of interoperability problems when people try to pretend that XML is a data model, not a syntax; they are (to quote you) "trying to mask the existence of XML altogether". Your application and mine probably have profoundly different needs in the data-modeling department, XML lets us interoperate anyhow. I've always thought that's where the big win was.
--Tim Bray on the xml-dev mailing list, Monday, 10 Feb 2003
When XML 1.0 began, it used some fairly simple criteria to create a markup technology that was (relatively) easy for programmers to implement and use. I think XML failed the Desperate Perl Hacker test, but it succeeded to the point where lots of parsers became available and tools around those parsers became available.
--Simon St.Laurent on the xml-dev mailing list, Friday, 02 Aug 2002
A lot of the business in the Internet marketplace, for reasons that I cannot quite fathom, had what I call "shoestring operations". One example of "shoestringing" would be to not mirror critical drives. Another would be to skip backups, or to only do them infrequently. Another would be to hire a "technical staff" that couldn't code/support/maintain/whatever their way out of a paper klein bottle.
Basically, it is "operating on the cheap". As with lacking insurance, there's a gamble involved. If nothing goes wrong, you win. If something goes wrong, you lose.
--Andrew Gideon on the wwwac mailing list, Thursday, 28 Aug 2003
DSDL is necessary because other XML schema languages (primarily W3C XML Schema) do not meet the needs of "document heads", and document validation is too complex to be done using a single language. Our goal is to propose a set of specifications which will include a framework, several schema languages (including Relax NG and Schematron), a datatype system, and other pieces needed for document validation.
--Eric van der Vlist
Read the rest in XML.com: DSDL Interoperability Framework [Apr. 30, 2003]
I honestly don't see why they bother with WordML; what is the *point* of storing data in XML if the schema is so hideous and proprietary than no one can use it without proprietary API support? What advantages does WordML have over the HTML- like stuff that current versions of Word generate on request? At least you can tidy.exe the HTML-like stuff into standard XML, but what can you do with WordML except load it into Word ... unless of course you are an XSLT uber-geek?
--Mike Champion on the xml-dev mailing list, Friday, 11 Apr 2003
I've never been one for pussyfooting around when it comes to liberating what some corporation or mogul calls "private property." I don't really give a shit about capitalism. I think it's a scam. Rich guys who own everything trade stocks, and the rest of us, who own the vast majority of nothing, watch welfare wither away. If we make something beautiful and try to make a living by selling it, we can't own it. My beautiful thing will be the property of some company that has slapped a cover on it.
I'll leave it to Lawrence Lessig to explain how copyright limitations can nourish free trade and moneymaking. I'll let Declan McCullagh explain why there is no contradiction between capitalism and civil liberties for all. I don't care if my file-sharing cripples the economy. I want to rebel against the property holders, the people who took away our beautiful things and called them commodities. Until culture belongs to all of us equally, I will continue to infringe.
--Annalee Newitz
Read the rest in AlterNet: TECHSPLOITATION: Why I Infringe
I am always amazed, and appalled, when I fire up a packet monitor and watch the continuous flow of useless junk that arrives at my demarcation routers' interfaces.
That background traffic has increased to the point where it makes noticeable lines on my MRTG graphs. And I have little reason for optimism that this increase will cease. Quite the contrary, I find more reason to be pessimistic and believe that this background noise will become a Niagara-like roar that drowns the usability of the Internet.
Between viruses and spammers and just plain old bad code, the net is now subject to a heavy, and increasing level of background packet radiation. And the net has very long memory - I still get DNS queries sent to IP addresses that haven't hosted a DNS server - or even an active computer - in nearly a decade. Search engines still come around sniffing for web sites that disappeared (along with the computer that hosted them, and the IP address on which that computer was found) long ago.
Sure, most of this stuff never makes it past the filters in my demarcation routers, much less past my inner firewalls. But it does burn a lot of resources. Not only do those useless packets burn bits on my access links, but they also waste bits, routing cycles, and buffers on every hop that those useless packets traverse.
--Karl Auerbach
Read the rest in Boston.com / News / Nation / Saboteurs hit spam's blockers
XML is a way to represent structured information as text. It has one established transform language and a couple more in design. There is no management component. Comparing it to relational database is like comparing a glider to an airline.
On the other hand, the notion that XML needs to be justified by some kind of "proof" is just ludicrous. Technologies are justified by utility.
Thank heaven relational database vendors have more common sense than relational zealots. The former know that relational database is not threatened by XML, any more than it was threatened by "object database" in the '80's. At most, it is another import/export format and a performance/tuning issue.
--Bob Foster on the xml-dev mailing list, Tuesday, 26 Aug 2003
XML sucks because it's being used wrongly. It is being used by people who view it as being an encapsulation of semantics and data, and it's not. XML is purely a way of structuring files, and as such, really doesn't add much to the overall picture. XML came from a document preparation tradition. First there was GML, a document preparation system, then SGML, a document preparation system, then HTML, a document preparation system, and now XML. All were designed as ways humans could structure documents. Now we've gotten to the point where XML has become so obscure and so complex to write, that it can no longer be written by people. If you talk to people in Sun about their libraries that generate XML, they say humans cannot read this. It's not designed for human consumption. Yet we're carrying around all the baggage that's in there, because it's designed for humans to read. So XML is a remarkably inefficient encoding system. It's a remarkably difficult to use encoding system, considering what it does. And yet it's become the lingua franca for talking between applications, and that strikes me as crazy.
--Dave Thomas
Read the rest in Plain Text and XML
All font tags do is double the bandwidth that's needed to view your site, while undercutting underlying document semantics that might help your page travel beyond the traditional desktop browser. They hurt you, they hurt your users and they offer no compelling benefit to offset the damage they do.
Close to 100% of all desktop browsers now in use can at the very least understand font styling created in CSS1. Anyone using a browser that can't do this -- and we're talking Internet Explorer 2 and Netscape 3 -- doesn't care whether your site is set in Verdana or Georgia or Times. They just want the information. There's no need to feed them 20K of font tags per page and there's certainly no need to force the rest of your users to download that junk with every new page they load. One little CSS file can handle all your site's font styling and much more and once downloaded, it stays in the visitor's cache, saving bandwidth on every page of your site.
Traditionally, font tags have been used not only to control presentation, but also to replace rudimentary HTML or XHTML structural markup, such as the paragraph tag or headline tags like h1 and h2. Even in a non-CSS environment, and there are very few of those out there, at least in the browser space, if you use good simple structural elements like the paragraph tag and the h3 headline, the meaning comes through whether people see your chosen font or not. Using structured markup instead of font tags and other 1997 junk makes your site as friendly to a Newton handheld or a text-only browser as it is to a modern desktop browser or a Web-enabled cell phone and at a fraction of the bandwidth and development cost.
--Jeffrey Zeldman
Read the rest in Meet The Makers - Creative people in a technical world.
Postel's dictum is in fact the problem here. If implementation A is liberal in what it accepts and implementation B is liberal but in different places, then finding conformance bugs in A and B can be difficult. It can also lead to interop problems when implementation C is brought into the picture, and has to "work around" the two non-overlapping liberalities.
--Rich Salz on the xml-dev mailing list, Sunday, 24 Aug 2003
There comes a point in the life cycle of any system when adding one more patch is the wrong solution to every problem. Eventually, it's time to rethink, refactor, and rewrite. For DocBook, I think that time has come.
--Norm Walsh
Read the rest in More Ruminations on DocBook
Since the idea of client-side XSLT is pretty much dead in the water, a good case can be made that it doesn't need a single standard either. We might be better off with multiple competing implementations, each with its own unique feature set. Stylesheets might not be portable amongst different processors, but you only use one processor at a time anyway!
Freeing XSLT's evolution from the W3C process would allow more room for experimentation and innovation. It would also provide an opportunity to see which ideas are worth keeping and which can be discarded, and then throwing the latter away!
--Joe English on the xml-dev mailing list, Thursday, 19 Jun 2003
The layering problem here is not a W3C one, but in part an IETF one: it goes to the poverty of text/* and application/*. The old ways of thinking about text (that we can all use ASCII, that our data is local and so will all use the same encoding, that our data is international and so will all use a single encoding, that some other magical application layer will look after encoding) are at their expiry dates.
--Rick Jelliffe on the www-tag mailing list, Monday, 21 Apr 2003
the whole issue with the Web is that it has been designed for people but that because of an unexpected huge success people have always wanted to use it for programs.
That was one of the goal of XML (SGML on the web so that programs can use the web to exchange usable documents) and this is what Web Services and the Semantic Web are trying to leverage on the success of a system designed for people to exchange between applications.
--Eric van der Vlist on the xml-dev mailing list, 24 Jul 2003
It is unlikely that a spec will be successful unless specialists in the field complain that it is far too simple for real-world use ("I've been working with markup since 1988, and I know that in industrial-strength projects we need to ..."). Pre-W3C HTML is the classic example, but remember that networking types once looked down their noses at TCP/IP as well ("It's fine for academic research, but ..."). Sometimes the specialists get their revenge in v.2 by joining the process and smothering the spec to death with new features.
--David Megginson on the xml-dev mailing list, Sunday, 27 Oct 2002
Stop trying to pin down arbitrary concepts using a unique URI. It is not necessary for there to be a canonical URI to identify "the Porsche 911". It is sufficient to be able to say "the car in *this picture*" or the car "described in *this advertisement*". Question: does tel:555-1234 identify a company, a department, a telephone handset, the person who answers it, the employee role of the person who answers it, the person who is *supposed* to answer it, or none of the above? Answer: it doesn't matter! Because any reasoning agent can say "the company whose number is..." or "the employee who answers when you call..." or any other necessary clarification. If telephone numbers do not identify a unique concept, neither do URIs.
--Michael Day on the www-tag mailing list, Thursday, 24 Jul 2003
A DOM tree is not XML. It's related to XML, but if you pass me some instance of a DOM tree, it's not XML unless it's unicode characters with angle brackets. I have the specifications on my side on this one and I'm not backing down. I'm not denying that someone might want to pass DOM trees around, I'm just saying that this gives up most of the interoperability advantages of XML and shouldn't be billed as interchanging XML.
--Tim Bray on the xml-dev mailing list, Thursday, 05 Dec 2002
in the general case it is not possible for any XSLT implementation to define the appropriate collation rules for all possible uses of sort--the variance even within a single language is too great, as evidenced by, for example, the discussion of back-of-the-book index sorting in the _Chicago Manual of Style_. In addition, the Unicode standard is very clear that the ordering of characters in the Unicode character set does not define the collation sequence for any language or writing system. While most alphabetic languages have a natural or default collation order, sylabic and ideographic languages mostly do not.
--W. Eliot Kimber on the xsl-list mailing list, Saturday, 09 Aug 2003
The Internet is the worst polluter of all. Spam isn't even pollution, it's attention theft. But even legitimate email is typically copied to more people than necessary and contaminated by excess verbiage and endless reply loops. The Web is a procrastination apparatus: It can absorb as much time as is required to ensure that you won't get any real work done. Sites overflow with either low-value stream-of-consciousness postings or bland corporatese.
Studies of content usability typically find that removing half of a website's words will double the amount of information that users actually get.
Let's clean up our information environment. Are you saying something that benefits your customers, or simply spewing word count? If users don't need it, don't write it. Stop polluting now.
--Jakob Nielsen
Read the rest in Information Pollution (Alertbox)
The first thing to remember is XML is syntax not semantics. Repeat it to yourself often. It is the biggest mistake made by many people who work with XML, even the supposedly experienced old hands. This mistaken assumption leads to statements like "XML is a self describing format" when in truth it is no such thing since self describing implies that the semantics of an XML document are self contained and inherent in the document which is a bogus claim that is obvious to anyone who's spent 5 minutes working with XML.
--Dare Obasanjo
Read the rest in kuro5hin.org || Another One For Jon Udell
My attitude with reuse is that reuse is something you evolve. You build an application to solve the problems of the application. If you build another similar application, then you begin to factor out some common pieces. If you build a third similar application, you factor out more common pieces. Then you'll begin to have something like a reusable framework. My definite recommendation is don't attempt to define a reusable framework first and then build applications on top of it. Rather, evolve the framework while building the applications.
--Martin Fowler
Read the rest in Flexibility and Complexity
Very small teams built the early database systems. A small team at Oracle built the original Oracle, and there were small teams at Informix, Ingress, Sybase, and IBM.
Twenty-five people can do a pretty full-blown system, and ship it, and support it, and get manuals written, and test it. The Postgress and MySQL teams are on that scale and likely represent the leading open-source DBMSes out there. Maybe the teams are getting larger at this point. A few years ago the DBMSes lacked transactions, optimization, replication, and lots of other cool features, but they are adding these features now.
The lack of a common code base is one of the things that has held back the database community and has been a huge advantage for the operating systems community. The academic world has had a common operating system that everybody can talk about and experiment with.
It has the downside of creating a mob culture. But the positive side is everybody has a common language and a common set of problems they are working on. Having MySQL as a common research vehicle is going to accelerate progress in database research. People can do experiments and compare one optimizer against another optimizer. Right now, it is very difficult for one research group to benefit from the work of others.
--Jim Gray
Read the rest in ACM Queue - Content
RSS should be a poster child for XML namespaces, because everyone and his dog wants to extend it but keep the core syntax / semantics. Instead, namespaces are (as Danny Ayers points out elsewhere, can't remember where offhand) one of the principal cleavage points in the RSS world. Are those resisting namespaces just being stupid/stubborn, or are they the "canaries in the coalmines" dropping over from the toxic namespace fumes? I don't know ... but I hear the sound of people voting with their feet. Maybe the XML Supreme Court should steal the election and suspend civil rights until this non-orthodoxy is corrected :-) But seriously, this challenges the XML world to show that the namespace spec really adds more benefit than cost in the real world, or to clean it up until it does.
--Mike Champion on the xml-dev mailing list, Monday, 21 Jul 2003
One of my hopes for the W3C Binary Infosets meeting is that someone realizes that markup is a crappy solution for a lot of the projects people are using it for, and that perhaps they'll be able to come up with better answers more appropriate to the tasks and programming cultures where XML has landed.
--Simon St.Laurent on the xml-dev mailing list, Thursday, 31 Jul 2003
If we want to assign a URI to everything including digital documents, then we have the choice that a URI representing something other than a digital document must return an error when GETted, or that some digital documents cannot be given RDF properties.
TBL has said that "http://www.w3.org/Consortium/" is the URI for the W3C consortium. But he has not said what the URI is for the hyperdocument which begins "The World Wide Web Consortium was created in October 1994". It cannot be the same URI on pain of contradiction.
--John Cowan on the xml-dev mailing list, Thursday, 24 Jul 2003
I could use PUT and DELETE in an XForm. Only GET and POST are allowed in HTML
--Bill De Hòra on the xml-dev mailing list, Wed, 23 Jul 2003
Xerces, like the rest of Apache, is open source software. If you have complaints about code quality, you are more than welcome to get involved in helping to improve it. Or you can go with a purchased copy rather than a free copy; generally, the largest advantage of doing so is that you get an actual customer support team.
--Joseph Kesselman on the xerces-j-user mailing list, Thursday, 24 Jul 2003
In case anyone doesn't know, there is an xml-technology specific newsgroup: comp.text.xml. It seems of real use to people who are, e.g., having trouble using XML Schema or DTDs, and the "Is XML a bagel or a database?" kind of question usually draws a constructive response.
--Bob Foster on the xml-dev mailing list, Wed, 23 Jul 2003
If one accepts the assertion that XML itself is only syntax, then namespaces work reasonably well. If one attempts to use them with any other semantic, results vary.
--Claude L Bullard on the xml-dev mailing list, Tuesday, 22 Jul 2003
RSS is much like HTML -- it evolved because the need for it was there, but is now reaching a point where it is becoming too integral to the overall structure of the web not to be pushed into a formal process. Personally, I would love to see it be submitted as a note into the W3C, which would in turn pretty much force it into at least standards compliance with the rest of the XML technology base.
--Kurt Cagle on the xsl-list mailing list, Monday, 21 Jul 2003
the insanity of not conforming to underlying xml standard means that RSS is just one of those 'almost' technologies, that seemed to be the right way....but in the end compromised itself; and now it just looks like an embarressing mistake. No doubt, embarressing mistakes like RSS get used every day all the time in our industry, so arguing the case against RSS is a bit moot, it is a successful technology; but for all its simplicity its typical usage imposes a barrier to integrating it for no reason.
--Jim Fuller on the xsl-list mailing list, Monday, 21 Jul 2003
Standardizing XML's syntax - and whatever semantics were needed for that, as I acknowedged - had clear benefits. The waves of supposedly semantic standardization that have followed have a much more muddled record, to put it politely.
XML's creators had the substantial advantage of three decades of work to reduce to the smallest possible set of tools, and I hope that after another decade we'll be able to boil those down further. In the meantime, however, I don't feel at all committed to standardizing and standardizing and standardizing.
--Simon St.Laurent on the xml-dev mailing list, Friday, 18 Apr 2003
the fraud at HealthSouth was not perpetrated using XML documents and that the inability to audit it, which Ernst and Young pleads, was not the effect of web services practice. However, the fundamental principles of transaction process design which this fraud (like so many recently!) illustrates, albeit in misapplication, are those very points which as regularly as they are misunderstood ignite predictable permathreads in our discussion on this list. Fraud was possible at HealthSouth because too many parties assumed that what looked like a transaction was a transaction and, worse, each assumed that it was a transaction corresponding to his own particular understanding of a transaction. This is the Fallacy of Extrapolating from Validation, and it was ruthlessly exploited by those who designed this fraud. Conformance to a content model or to any schematic is quite simply just that and does not imply that any such valid document instance may be (forget about will be!) reliably instantiated as a particular data structure . Document instances of content models or of other schematics are inevitably in many-to-many relationship with instantiated data structures expressing the same content model or schematic. That can be narrowed to a one-to-one relationship only by constraining away all of the things that make the document a document, so that you are effectively transmitting the particular data structure itself.
--W. E. Perry on the XML DEV mailing list, Friday, 28 Mar 2003
Today most web pages are composed in large part of vectors that are being delivered to the user as relatively bulky bitmap graphics. Consider the Google web page. It is famous for being sparse and fast to load. But even that page could be made faster with vector graphics.
The Google page consists of three pictures and an HTML document. With inline SVG, it could be a single XHTML/SVG document. This would download in a single network transaction instead of three. Client-side code could manipulate and transform the graphics and text together.
After you do the search, today's Google takes you to another page. The same images appear on the next page but they are at a different size. Because bitmaps scale poorly, they are delivered as two completely new graphics. Even though the bigger version is cached, the smaller version is downloaded from scratch. In the future, the image could be reused by reference and scaled to the right size, even if it had been included as inline markup in the Google main page. Google likes to add holiday greetings and localization to their images. SVG would allow this to be done using layers and overlays rather than entirely new graphics. Once again, this is cache efficient, which improves performance.
If SVG could improve the efficiency of Google this much, imagine what it could do for more complex, shape-based layouts like slate.com or cnn.com. SVG could noticeably improve the performance of the whole Web. But better performance is just the beginning. Things get really exciting when you consider the much richer Web that SVG enables.
--Paul Prescod
Read the rest in XML.com: SVG: A Sure Bet [Jul. 16, 2003]
any standards committee that *doesn't* follow the principle of "if in doubt, leave it out" should be forced to keep circulating their ever more bloated specification amongst themselves in a feedback cycle until their mail servers all crash and the evil product of their activities is lost to the bit bucket. WXS seemed to be firmly on this track, but somehow the damned thing escaped to the wild before the inevitable collapse. I consider it a virus.
--Dennis Sosnoski on the xml-dev mailing list, Thursday, 19 Jun 2003
PDF is great for one thing and one thing only: printing documents. Paper is superior to computer screens in many ways, and users often prefer to print documents that are too long to easily read online.
For online reading, however, PDF is the monster from the Black Lagoon. It puts its clammy hands all over people with a cruel grip that doesn't let go.
--Jakob Nielsen
Read the rest in PDF: Unfit for Human Consumption (Alertbox)
As an independent organization, the Mozilla project will have even more freedom to innovate and provide meaningful choice to users on all computer environments. A competitive, standards-compliant browser suite is vitally important to maintaining freedom and innovation on the Internet, so Im delighted to make a contribution
--Mitch Kapor
Read the rest in Mozilla Foundation Announcement
Microsoft (and numerous other vendors - I am not just picking on them) has _ALWAYS_ played the standards game when behind, and proprietary extensions when ahead. There is a _reason_ web browser releases slowed from every 6 months to every 2 years and why Microsoft has shown little interest in implementing _new_ XML related standards (or even in bringing their browser into strict compliance with the existing standards) in the last year. They don't have to - they are the industry leader by a substantial margin as a consequence of their uncontested monopoly on the desktop and have no need to enhance their customer's ability to 'switch' to competing vendors.
--Benjamin Franz on the xml-dev mailing list, Monday, 14 Jul 2003
In my experience users of XML Schema language, particularly W3C XML Schema, fall into two broad classes. Those who want validation of XML documents (i.e. a message contract) and those who want to create Type Augmented Infosets (i.e. strongly typed XML). RELAX NG does the former but not the latter. W3C XML Schema does both, in my experience it doesn't do enough of the former and too much of the latter.
--Dare Obasanjo on the xml-dev mailing list, Thursday, 10 Jul 2003
The identification and vilification of external enemies. This is a very common pattern. Anyone who was around the Open Source movement in the mid-Nineties could see this all the time. If you cared about Linux on the desktop, there was a big list of jobs to do. But you could always instead get a conversation going about Microsoft and Bill Gates. And people would start bleeding from their ears, they would get so mad.
If you want to make it better, there's a list of things to do. It's Open Source, right? Just fix it. "No, no, Microsoft and Bill Gates grrrrr ...", the froth would start coming out. The external enemy -- nothing causes a group to galvanize like an external enemy.
So even if someone isn't really your enemy, identifying them as an enemy can cause a pleasant sense of group cohesion. And groups often gravitate towards members who are the most paranoid and make them leaders, because those are the people who are best at identifying external enemies.
--Clay Shirky
Read the rest in Shirky: A Group Is Its Own Worst Enemy
saying "thou shalt always use an XML API, or thou will perish" is probably a bit much. As another poster said, the experience of the developer is a key factor in the decision. Of course I've seen enough carelessness out there that advising people to use an API has become my default position. It's pert self-preservation. Let me tell you, it really bites to have to follow workflow back and forth in a complex project to see who is spitting out the broken XML.
--Uche Ogbuji on the xml-dev mailing list, Thursday, 19 Jun 2003
Un schéma ne suffit pas à documenter un vocabulaire XML et il est regrettable que les expressions "publier un schéma" ou "répertoire de schémas" soient rentrées dans le langage courant laissant à penser qu'un schéma suffit à ce qu'un vocabulaire soit immédiatement utilisable par tout informaticien.
--Eric van der Vlist
Read the rest in Quel langage de schéma XML choisir pour chaque usage ?
The test of whether a company understands the value of standards is when it recognizes that conformance is good even when the standard is bad.
--Michael Kay on the xml-dev mailing list, Wed, 9 Jul 2003
I am really tired of reading press releases about W3C accomplishments when none of it gets enabled on the Web until someone at Apache makes it happen.
--Roy T. Fielding on the www-tag mailing list, Wed, 9 Jul 2003
There are two fundamental problems with WXS datatyping. The first is its design: it's not a type system -- there is no system -- and not even a type collection. Rather, it's a collection of collections of types with no coherent or consistent set of interrelations. The second problem is a single sentence in the specification: "Primitive datatypes can only be added by revisions to this specification". This sentence exists because of the design problem; lacking a concept for what a primitive data type is, the only way to define new types is by appeal to authority. The data type library is wholly inextensible, internally inconsistent, bloated in and incomplete for most application domains.
--Amelia A. Lewis
Read the rest in XML.com: Not My Type: Sizing Up W3C XML Schema Primitives [Jul. 31, 2002]
The problem is, once we store data in a non-transparent, inaccessible format, then we need code to read it, and that code disappears. Code is disappearing all the time. You probably can't go to a store and ask for a copy of Word 1, or whatever the first version of Word was called. So we are losing vast quantities of information, because we can no longer read the files.
One of the reasons we advocate using plain text is so information doesn't get lost when the program goes away. Even though a program has gone away, you can still extract information from a plain text document. You may not be able to make the information look like the original program would, but you can get the information out. The process is made even easier if the format of the plain text file is self-describing, such that you have metadata inside the file that you can use to extract out the actual semantic meaning of the data in the file. XML is not a particularly good way to do this, but it's currently the plain text transmission medium du jour.
Another reason for using plain text is it allows you to write individual chunks of code that cooperate with each other. One of the classic examples of this is the Unix toolset: a set of small sharp tools that you can join together. You join them by feeding the plain text output of one into the plain text input of the next. There's no concept of trying to make sure the word count program outputs things in a format that's compatible with the next tool in the chain. It's just plain text to plain text, and that's a very powerful way to do it.
--Dave Thomas
Read the rest in Plain Text and XML
the other strength of SAX comes when you're going to be building an in-memory tree anyway, but it does not happen to be a DOM tree. Using the low-level events from SAX to build (say) a tree of geographical coordinates is much more efficient than building a DOM tree, then building a second tree of geographical coordinates from that, then garbage-collecting the DOM tree. In that case, most programmers in the project will never see SAX -- the load/save library should hide it completely.
--David Megginson on the xml-dev mailing list, Saturday, 19 Apr 2003
the name "default namespace" was poorly chosen because it implies it acts as a default in the absence of something. It also implies there's just one. Simply think of a default namespace as any namespace that happens to have an empty string prefix.
--Jason Hunter on the jdom-interest mailing list, Thursday, 03 Jul 2003
Some of us really REALLY want to be able to deal with the bits on the wire and REALLY like the open-ness and interoperability that gives us. Others really REALLY want to take the bits on the wire away and present us instead with an API that has 117 entry points averaging 5 arguments and try to convince us that this is somehow equivalent. XML, for the first time in my professional career, represents a consensus on interoperability: that it is achieved by interchanging streams of characters with embedded markup. Since about 15 seconds after XML's release, the API bigots have been trying to recover from this terrible mistake and pretend that the syntax is ephemeral and the reality is the data structure, just read chapters 3 through 27 of the API spec, buy the programmer's toolkit, sign up for professional services and hey-presto, you'll be able to access your own data, isn't that wonderful!?!?
But you're not going to take the bits on the wire away from us without a huge messy noisy fight down to the last ditch.
--Tim Bray on the xml-dev mailing list, Thursday, 05 Dec 2002
Premature standardization with little-to-no implementation experience has led to some really awful standards, and a lot of the things being made into Official W3C Recommendations don't really need to be standardized in the first place, or at least not yet! XQuery is IMO a good example of this.
--Joe English on the xml-dev mailing list, Thursday, 19 Jun 2003
The IETF has an explicit contract with Unicode: "We'll use your normalization algorithm if you promise NEVER, NEVER to change the normalization status of a single character." Unicode has already broken that promise four times, so its credibility is shaky.
--John Cowan on the xml-dev mailing list, Friday, 27 Jun 2003
In a parallel universe where CSS layout and structured markup had always been the norm, it would be hard to wrap your brain around table layouts and spacer pixels. Youd be like, But I can do this with the CSS margin. Why do I have to use this stupid transparent pixel GIF image? In that same parallel universe where all browsers had always supported the same standard scripting language and Document Object Model, if you suddenly had to code for six incompatible browsers, youd say, This is impossible. Im sorry, doesnt this medium have any standards any more? Six code forks just to verify that address text entered in a form field is not malformed? Youve got to be kidding.
--Jeffrey Zeldman
Read the rest in Meet The Makers - Creative people in a technical world.
This is all very informal, but I heard someone say a good programmer can reasonably maintain about 20,000 lines of code. Whether that is 20,000 lines of assembler, C, or some high-level language doesn't matter. It's still 20,000 lines. If your language requires fewer lines to express the same ideas, you can spend more time on stuff that otherwise would go beyond those 20,000 lines.
A 20,000-line Python program would probably be a 100,000-line Java or C++ program. It might be a 200,000-line C program, because C offers you even less structure. Looking for a bug or making a systematic change is much more work in a 100,000-line program than in a 20,000-line program. For smaller scales, it works in the same way. A 500-line program feels much different than a 10,000-line program.
--Guido van Rossum
Read the rest in Programming at Python Speed
Python uses whitespace to *force* you to lay out your code so that the control structure is *obvious*. That leaves your mind free to concentrate on what the program really does.
Its sort of like separating content from presentation (an XML mantra) but applied to software.
--Sean McGrath on the xml-dev mailing list, Wed, 23 Oct 2002
At best, SOAP introduces a level of indirection to such XML message exchanges by embedding an XML message in a SOAP envelope. Since the SOAP envelope can carry metadata about the original XML message, such as processing instructions, the envelope can aid a Web service in processing that message. At worst, SOAP makes it difficult, if not impossible, to verify the validity of an XML message traversing between two Web services.
--Frank Sommers
Read the rest in Why Use SOAP?
One interesting thing is that REST stands for Representational State Transfer, and one thing that REST does not talk at all about is how you actually represent the state, despite the fact that that's the name. Conversely, Simple Object Access Protocol (SOAP) does not talk about any way in which you access objects; it just talks about how you represent state and do transfer.
--Sam Ruby
Read the rest in Web services visionary
Another thing you have to bear in mind is that performance optimizations are quite implementation and release dependent. When you get a new version of Java, you really ought to undo every performance optimization you ever made, then reapply them to make sure they still make the program go faster. Often you'll find that a performance optimization you did in a previous version of the virtual machine (VM) or optimizing compiler will actually make you slower now. A performance optimization that helped before may actually defeat the optimizations the new compiler or VM is doing.
--Martin Fowler
Read the rest in Tuning Performance and Process
XML output is almost always more complex than you think at any given time. I'm sure that even having written a lot of XML output code, I haven't exhausted the realm of potential gotchas. Using an XML API keeps the specialization where it belongs.
--Uche Ogbuji on the xml-dev mailing list, Thursday, 19 Jun 2003
The other sore spot is Microsofts FrontPage, which many developers at public sector institutions are stuck with. FrontPage is not a Web editor, its an Internet Explorer production tool. There is a difference. FrontPage is designed to make sites that only work in Microsofts browser. This is not just my opinion, its what Bill Gates said in testimony during the trial. Few commercial designers and developers use FrontPage, but as I said, too many folks in the public sector are told they must use it because theres no money in the budget for an additional Web editor like Dreamweaver.
--Jeffrey Zeldman
Read the rest in Meet The Makers - Creative people in a technical world.
One of my regrets about XML is that we didn't get rid of attribute normalization and I think we should either have required > to be escaped everywhere or should have allowed ]]> outside CDATA sections.
--James Clark on the xml-dev mailing list, Friday, 20 Jun 2003
Considering actual user needs, striving for simplicity, basing your design on mathematical principles, etc. are powerful repressive forces. If such considerations had held back WXS, we might not today enjoy interleave for dummies, object orientation without objects, or even non-commutative set union, the mighty engine that drives XQuery validation, and makes possible the typeswitchlottery feature.
--Bob Foster on the xml-dev mailing list, Thursday, 19 Jun 2003
Dataheads think of an element as a container for its content, and if the container is removed, the content goes to Tumbolia with it. Docheads think of elements as basically annotations of ranges, and if the annotation is removed, the underlying content remains.
--John Cowan on the xom-interest mailing list, Wed, 18 Jun 2003
You can get an idea of how long browser support will take by looking at Cascading Style Sheets -- CSS 1 became a recommendation in 1996, CSS 2 in 1998. Years later we're still waiting for the major browsers to give us full compliance. Given the radical nature of XHTML2, I wouldn't expect any browser maker to jump in ahead of the game, making implementations before the recommendation is final.
--Owen Leonard on the XHTML-L mailing list, Tuesday, 25 Mar 2003
The Web *is* a triumph of keep it simple, 80/20, evolutionary design principles. Up-front design to eliminate the corner cases we have to deal with today would not have led to a better Web, it would have led to no Web; we'd be faced today with far worse problems of interoperability between more highly designed but incompatible systems. If HTTP and HTML hadn't been dirt simple in their first generation, they wouldn't have spread like wildfire. Think HTML is kludgy and under-designed? How would you like to be using Blackbird on Windows, PDF on Macs, Frame on Unix, and trying to build anything resembling what we have today out of all these highly-designed pieces?