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 I'm 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. You'd 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, you'd say, This is impossible. I'm sorry, doesn't this medium have any standards any more? Six code forks just to verify that address text entered in a form field is not malformed? You've 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 Microsoft's FrontPage, which many developers at public sector institutions are stuck with. FrontPage is not a Web editor, it's an Internet Explorer production tool. There is a difference. FrontPage is designed to make sites that only work in Microsoft's browser. This is not just my opinion, it's 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 there's 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?
--Mike Champion on the xml-dev mailing list, Thursday, 24 Jan 2002
When you release 1.0, you might want to actually keep it kind of quiet. Let the early adopters find it. If you market it and promote it too heavily, when people see what you've actually done, they will be underwhelmed. Desktop.com is an example of this, so is Marimba, and Groove: they had so much hype on day one that people stopped in and actually looked at their 1.0 release, trying to see what all the excitement was about, but like most 1.0 products, it was about as exciting as watching grass dry. So now there are a million people running around who haven't looked at Marimba since 1996, and who think it's still a dorky list box that downloads Java applets that was thrown together in about 4 months.
Keeping 1.0 quiet means you have to be able to break even with fewer sales. And that means you need lower costs, which means fewer employees, which, in the early days of software development, is actually a really great idea, because if you can only afford 1 programmer at the beginning, the architecture is likely to be reasonably consistent and intelligent, instead of a big mishmash with dozens of conflicting ideas from hundreds of programmers that needs to be rewritten from scratch (like Netscape, according to the defenders of the decision to throw away all the source code and start over).
--Joel Spolsky
Read the rest in Joel on Software - Good Software Takes Ten Years. Get Used To it.
I've developed a number of vocabularies that could have used XInclude, but ended up using a simpler ad-hoc solution instead. The main reasons I didn't use XInclude are: XPointer was unnecessary for my needs (relative URIs were sufficient, I only needed whole-document transclusion); XPointer was unimplementable (at least by me); and in a number of cases leaving XInclude out meant I could leave out XML namespaces as well (since nothing else in the vocabulary called for them).
--Joe English on the xml-dev mailing list, Friday, 09 May 2003
Back in the days when I had time to hang out on the xslt list I found myself giving a use case where strong typing would help us. Now-a-days, I've worked around it so much I no longer want it. Essentially, we can annotate a node from the back end with a type attribute and be done with it once and for all; pretty much everything we ever needed to do with types is now possible.
--Peter Hunsberger on the xml-dev mailing list, Tuesday, 10 Jun 2003
OOP has made a virtue of binding data and behavior. (OOP's XML integration problems strike me as eerily familiar to its RDBMS integration problems, where a similar separation is popular.)
Trying to explain that mixing data and processing is fine while you're processing the data and awful when you're transferring the information between dissimilar systems doesn't always seem to go over well. Programmers seem to put a lot of effort into abolishing "dissimilar" instead of taking advantage of the separation. At least that's the lesson I've seen in most of this Web Services stuff...
--Simon St. Laurent on the xml-dev mailing list, Monday, 13 Jan 2003
The sad truth about the computer industry these days is that it is this last case that is dominating a broad range of standards activities. Standards are regularly created and adopted before anyone has performed the experiments necessary to determine if they are sensible. Even worse, standards are getting accepted before they are even written, which is a truly ridiculous situation.
How this arises is clear: standards are increasingly being viewed as competitive weapons rather than as technological stabilizers. Companies use standards as a way to inhibit their competition from developing advantageous technology. As soon as technical activity is observed by political/economic forces, their interest rises dramatically because they see a possible threat that must be countered before it gains strength.
The result of this is a tremendous disservice to both users and consumers of technology. Users get poor quality technology, and because of the standards process, they're stuck with it.
--James Gosling
Read the rest in Phase relationships in the standardization process
I would like a thorough review of XML for robustness and reliability, and soon. The idea that the class of parser should determine the information to be presented to an application is incoherent. The question should not be 'how do we simplify XML?' but 'how do we make it more robust and reliable?' Ends before means; Viagra not circumcision!
--Rick Jelliffe
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
The big issue is not whether you use GIF or PNG. The big issue is whether you let a patent holder become a censor for your communications.
--Don Marti
Read the rest in Bell tolling for PNG graphics format? | CNET News.com
the rude shock is that XPath 2.0 has kept the name XPath giving the false impression that XPath/XSLT 1.0 users would need to migrate from one to the other!
To me they are different languages and there is no special reason to move to XPath 2.0 (unless of course you really need its features).
--Eric van der Vlist on the xml-dev mailing list, Friday, 06 Jun 2003
SOAP/XMLPP have created an incompatible subset of XML such that general-purpose XML generators cannot reliably be used to generate their messages, and general-purpose XML processors cannot reliably be used to receive them.
--Tim Bray on the www-tag mailing list, Tuesday, 01 Apr 2003
SAX is a terribly difficult way for programmers to deal with XML, especially if they are already struggling just to get their minds around XML itself.
The problem is that they often hit a point where they have no choice -- what works fine in the small, proof-of-concept implementation suddenly falls to pieces under real-world-scale load testing in a busy server. That's why we see so many programmers posting to xml-dev about SAX mid- to late-project, rather than at the during planning -- they've come to the point where learning SAX is less painful than spending another month of late nights and weekends trying to figure out some other way to make their server handle more than a couple of hits per second.
In summary, then, SAX is the root canal of XML programming -- you try less painful solutions first, but if nothing works, it's time to lie back in the chair, close your eyes, and open wide, to avoid losing your teeth altogether.
--David Megginson on the xml-dev mailing list, Saturday, 19 Apr 2003
"Pull" APIs sometimes make the consumer's life considerably easier at the cost of sometimes making the producer's life considerably more difficult. It's easier to report good performance numbers in your component when you're in control of the processing loop. As a result, every step in the processing chain really wants a pull API on its input side and a push API on its output side...
--Joseph Kesselman on the xerces-j-user mailing list, Monday, 12 May 2003
Most of the time there is no manual. If I give you a Word 1 file, where's the manual? If I ship you the output of my stock controller system, where's the manual? If I'm gone, if my program's gone, what are you going to do with that file? There are terabytes of data sitting around in an unusable state, because the software that reads them is gone. Yes, you could probably sit there and reverse engineer it, but it would be a whole lot easier to reverse engineer it if it were self-describing.
--Dave Thomas
Read the rest in Plain Text and XML
Truth is that designing a data format -- in XML or plaintext -- is hard work, and most people do a very poor job of it. (Raw) XML simplifies many of these issues. With XML, all of a sudden people can interchange data files without having to think about nasty grammar issues. Either an XML file you generate/receive is syntactically correct, or it isn't.
There's a *huge* benefit there, as Tim Bray points out every month or so. If I'm writing a program to parse your XML data, and my program barfs due to a well-formedness error, I know you are the guilty party. If your data parses xmlwf, then I know the problem is with my buggy code.
--Adam Turoff on the xml-dev mailing list, Tuesday, 6 May 2003
since my system will have more users than implementers, it is quite all right to make the implementer's life complex to make the user's life simple. People often say, "Oh, I will design it this way, because I have this kind of data structure and that kind of data structure, so I'll just allow people to merge them together to get this result." But the real question is what does the user want? It may be easy for you to put these two data structures together and hard for you to do what the user wants. But if you don't do what users want, then they will have to do it themselves. If they do it themselves, then you can expect they will do so 1700 different times on top of your API with more bugs and more complexity. The real reason RMI is easy compared to CORBA is because of that attitude, putting what users want first. They want to invoke a method. Okay, how do you make invoking a method as natural as possible without pretending things that aren't true? Well, they want to pass in actual objects as parameters. OK, but the runtime figures out how to get objects to the other side, not the programmer.
--Ken Arnold
Read the rest in Perfection and Simplicity
Although innovation is great on the research side, real-world systems should use well-tested techniques wherever possible. For example, on the algorithm side, we use RSA, triple DES, AES, and SHA-1 at Cryptography Research unless we have to use something else. (This is rare.) We use these algorithms because they are well reviewed, making the risk of an unexpected cryptanalytic attack low. In contrast, catastrophic flaws in new schemes are very common.
--Paul Kocher
Read the rest in Slashdot | Security Expert Paul Kocher Answers, In Detail
XML today certainly isn't what I anticipated by the phrase "SGML on the Web".
--Andrew Watt on the xml-dev mailing list, Thursday, 13 Feb 2003
semantic web architecture != HTTP 1.1
This debate has always been at the interface between the Web and the Semantic Web. The Web doesn't care about what a URI denotes, only what representations can be obtained. But the Semantic Web doesn't care about what representations can be obtained but what the URI denotes.
--Patrick Stickler on the www-tag mailing list, Wed, 22 Jan 2003
Simplicity has real value on its own that makes the system more usable. It's the difference between reading a 100-page manual and reading a 500-page manual. It is more than five times the size.
--Ken Arnold
Read the rest in Taste and Aesthetics
createAttribute creates an Attr which is not fully compatable with namespace-aware processing. It is *NOT* equivalent to calling createAttributeNS() with the namespace either blank or null.
DO NOT use createAttribute(), setAttribute(), setAttributeNode() or createElement() if you have any choice whatsoever. Nodes produced using DOM2 calls will be compatable with DOM1... but the reverse is *not* true.
--Joseph Kesselman on the xerces-j-user mailing list, Wed, 23 Apr 2003
It is true that there is some useless cruft in XML that was included only for political reasons: public identifiers, notations and external entities serve no function that MIME types (or URIs -- sorry, Simon) and URLs couldn't serve, but we had to keep them in XML as part of an unwritten ceasefire agreement with the SGML old guard (*), which was still powerful at the time and could have seriously hindered acceptance of XML both inside and outside the W3C; the other part of that ceasefire was to pretend that XML and SGML would coexist, with XML for lightweight Web and SGML for so-called "serious enterprise applications" (the vendors put paid to that idea by abandoning SGML so fast that we couldn't keep up with the press releases).
--David Megginson on the xml-dev mailing list, Saturday, 15 Feb 2003
A standard syntax enables communication between separate components. A standard object model is useless for getting your bytes from "here" to "there."
--Rich Salz on the xml-dev mailing list, Friday, 23 May 2003
One of the early principles of GUI interfaces was that you shouldn't ask people to remember things that the computer could remember. The classic example is the Open File dialog box, which shows people a list of files rather than asking them to recall and type the exact file name. People remember things a lot better when they are given some clues, and they'd always rather choose something from a list than have to recall it from memory.
Another example is the menus themselves. Historically, providing a complete menu of available commands replaced the old command-line interfaces, where you had to memorize the commands you wanted to use. And this is, fundamentally, the reason why command line interfaces are just not better than GUI interfaces, no matter what your UNIX friends tell you. Using a command line interface is like having to learn Korean to order food in a Seoul branch of McDonalds. Using a menu based interface is like being able to point to the food you want and nod your head vigorously: it conveys the same information with no learning curve.
--Joel Spolsky
Read the rest in User Interface Design for Programmers
The United States spends more than $1 billion annually to examine patents. Despite this expenditure, the Patent Office has become a glorified diploma mill, routinely granting rights that should never have been issued. The patents wouldn't stand up in court, but they're expensive to litigate. So why are we forcing developing countries to follow our lead when we don't do a good job ourselves?
--Ralph Nader
Read the rest in hot seat
Ralph Nader, Patent Buster
The notion that you have to have an XML Schema or a DTD to work with this is one of the more unfortunate myths about XML out there. What you really need are basic relationships between senders and receivers. It's not like I need to create a formal contract every time I have a conversation - only some conversations require those.
--Simon St.Laurent on the cbp mailing list, Monday, 14 Apr 2003
My grandma used to say "a standard is, as a standard does". Participating in several list-servers for emerging standards as a potential user, I can add my observation that one reason for low success-rates from standards bodies is that they tend to be naïve about management of marketing requirements. Software companies work hard to support product marketing staff to force R&D to consider what's actually required by intended users. Many standards groups are like R&D departments enjoying a vacation from pesky market requirements (present company excepted!)
--Allen Razdow on the xml-dev mailing list, Monday, 19 May 2003
Perhaps the most important principle is this: Measure early, measure often. You can't effectively manage performance if you don't know the source of your problem. Programmers are notoriously bad at guessing where performance problems lie. Spending days tuning a subsystem that accounts for 1 percent of an application's total runtime simply cannot yield more than a 1 percent improvement in application performance. Instead of guessing, use performance measurement tools -- such as profiling or nonintrusive time-stamped logging -- to identify where your application spends its time and to focus your energy on those hot spots. After you tune, measure again. Not only will measuring help you concentrate your energy where it will count the most, but it will also provide evidence of the success -- or lack thereof -- of your efforts.
--Brian Goetz
Read the rest in Tweak your IO performance for faster runtime
For some piece of data to be marked up, some one has to first define, document, publish, and publicize the schema. After that the fun part starts: dealing with competing schemas and standardization process. After standardization, millions of users have to learn how to use the new schema. Whole lot of work and wait, for all parties involved, just to see a glimpse of XML Heaven.
What if we can skip all that? What if people markuped content using their own names and structures, not those dictated by the central committee? Will the resulting chaos be unsurmountable? I believe not. I believe that constraints and mechanisms inherent within human languages and social structures lead to what I call Emergent Markup Languages, common tags and structures that emerge from natural behaviors of individuals following simple rules like "call it what it is" and interacting with their immediate surroundings and neighbors.
--Don Park
Read the rest in Mozilla
Folks love TiVo for the same reason they loved the Mac in 1984 and the iPod in 2001: It gives control back to the end user. TiVo viewers call the shots regarding when, how, and -- soon -- even where they watch. Once content or access is purchased, the end user is in charge
--John Battelle
Read the rest in Business 2.0 - Magazine Article - Is TiVo NeXT?
The notion that every single XML vocabulary needs to be blessed by six high priests in some standards org in order to be a viable format for data interchange is so 1980's.
--Don Box
Read the rest in Don Box's Spoutlet
In general, advertising doesn't work on the Web, a fact that has been clear to usability researchers since 1997. Users ignore ads because they are contrary to the Web's basic imperative, which is to let users go where they want and get their information needs instantly gratified.
From the beginning, it was also clear that this indictment of Web advertising had two exceptions:
- Classified ads work because as far as users are concerned, they are content, not advertising: people actively seek out the classifieds when they are looking to buy. This explains the success of eBay, Monster/HotJobs, and many such sites. The superiority of Web classifieds portends dire times ahead for traditional printed newspapers, as their most lucrative income source continues to migrate online.>
- Search engine ads work because search engines are the one type of website that people visit with the explicit goal of finding someplace else to go. Thus, if users see an ad for what they're looking for, there is a high probability that they'll click that ad. Advertisers can satisfy a user's immediate needs because they target ads based on the user's query terms. (This also explains why ads on search engine homepages don't work: it's impossible to target the ad to the user's current quest until the server knows what that quest is.)
--Jakob Nielsen
Read the rest in Will Plain-Text Ads Continue to Rule? (Alertbox April 2003)
That seems to illustrate a problem fundamental to the committee design process. In committee, members hash and rehash arguments seemingly endlessly over every point in the specification, but by a political process that depends on the personalities on the committee, their intransigence or lack thereof, their personal and company agendas, and their knowledge or lack thereof of the problem domain, eventually arrive at a compromise. New members on the committee might tip the balance in another direction at any level of detail, resulting in the discard or rethinking of the entire body of work. It is difficult for committees to see such an event as progress. As a consequence, committees develop a hard shell that repels challenges to basic assumptions as a turtle's shell repels predators. In the end, nothing is so precious to a committee as its hard-won consensus, as, in truth, committee members often cannot even recall the chain of reasoning, politics and personality that led them to a particular conclusion.
A reviewer of committee work, on the other hand, is often in the dark about the consequences of committee decisions until the entire process has unfolded. A "Holy shit!" comment at that stage cannot penetrate the committee's shell, and the committee work product marches on of its own momentum.
--Bob Foster on the xml-dev mailing list, Thursday, 8 May 2003
The kindest description I've heard of the W3C XML Schema datatypes collection is "baroque". The most accurate is perhaps "baroquen".
--Amelia A Lewis on the xml-dev mailing list, Monday, 12 May 2003
Virtually any program that's going to operate on text of some sort can operate on plain text as the lowest common denominator. Very often you get into a state where you want to work with some program, but it's properties file has gotten corrupted such that the program won't even come up to let you change the property. If that file is in some binary format that needs the program itself to fix it, you're hosed. You've catch-22ed yourself right out of existence. If it's in a plain text format, you can go in with any generic tool--a text editor, whatever you like to use to deal with plain text--and fix the problem. So in terms of emergency recovery, or changes in the field, plain text is helpful. It provides another level of insurance.
--Andy Hunt
Read the rest in Plain Text and XML
Back in the Good Old Days, you could choose the base features that your problem needed for interoperability (or the code you were willing to write in the name of interoperability). DTD-Validity? Optional. Namespaces? Good idea, but optional. RDF? Take it, leave it, incorporate it later when people actually understand it. But at the end of the day, your data is either well-formed or it's not XML, and that's a surprisingly solid foundation for doing a lot more than we ever could with icky HTML, binary files or a plethora of plaintext formats.
What do we have today? A standards body that's dismissive of its hacker roots, acting more like an arbiter between vendors who are trying to build solutions to problems we're not trying to solve, and standardize products that we do not want to buy.
--Adam Turoff on the xml-dev mailing list, Saturday, 10 May 2003
There's something that's been bothering me about the way people have been raving about XML. One of the big claims is that because XML data is self-describing, with data wrapped by tags like <customerid>12345</customerid>, clients can figure things out even for documents that don't strictly adhere to their schema and specification. I hear claims that XML is more flexible, because providers of documents can be sloppy and just add new pieces of data here and there. Clients can just ignore tags they don't recognize and find data even if it is in the wrong place according to the schema. The Java class file is not XML, but like XML is a data structure and file format. There is a detailed specification for the Java class file that describes all the data and semantics, and also clearly defines the way in which class files can be extended. Providers and consumers of Java class files adhere strictly to the specification. This approach of strict compliance to a specification and schema makes more sense to me. I like what you have said about self-describing data, but I'm concerned about the leap that some XML enthusiasts seem to make that because the data is self-describing, the way in which a particular schema can evolve doesn't have to be clearly specified or followed, because they assume clients will just ignore anything they don't understand.
--Bill Venners
Read the rest in Silicon Valley
I am totally exasperated by the folks that want to remove PIs from XML. "Here's your Swiss Army Knife, norm, oh, but we broke off the small blade (the internal subset) and we've removed the tweezers (PIs), because you don't really need those. And for good measure we welded the corkscrew open (thou shalt always put elements in a namespace). Is there anything else we can do to help you?"
--Norman Walsh on the xml-dev mailing list, Friday, 24 Jan 2003
What many people really fear vis a vis Microsoft and XML is something like "don't worry you're pretty little heads about all that complexity, just use our GUI and wizards ... all will be fine ... trust us, trust us." So sorry, but trusting y'all up there in Redmond to ensure interoperability has not been a winning proposition in the past. Sticking with the simple subset of XML technology that can be understood by ordinary mortals and can be proven to interoperate with other Web Services tools is simple prudence, not paranoia about evil.
--Mike Champion on the xml-dev mailing list
We will be handing the programs we're writing today down to the next generation of programmers, and the ones after that. They will have to deal with this mess we've left behind. If we give them a load of gibberish consisting of binary data, they're going to have a harder time understanding it. If we give them nice plain text or XML files, it will be a lot easier to understand. Plain text will obviously require less mental energy to figure out.
--Dave Thomas
Read the rest in Plain Text and XML
I've worked with XPath for the last five years (counting the time very early on when it was a very different looking animal), and I think I've run into maybe three times in that period where having type-casting would have made things easier, and that principally because XSL lacked certain pieces which are finally coming into play in XSLT 2. When you add type you increase the complexity of the applications with relatively little beneft, UNLESS you are looking for ways to build a bundled data-aware object. In other words, the principal driving requirements for PSVI can be traced back to trying to turn XML into an OOP object. This can certainly be done, but at the cost of losing much of the flexibility that makes XML so useful.
--Kurt Cagle on the xsl-list mailing list, Wed, 19 Feb 2003
I'd take everyone who says XML is 'semi-structured data' (in contrast with relational data, which they believe to be 'structured') out back and engage in what Steve Zilles calls "severe counseling". The difference between data in third normal form and XML is not the difference between structured and semi-structured data: it's the difference between simple, regular structures that are easy to treat with the mathematical theory of relations and natural structures that are not so regular, not so simple, but very, very real, and very, very structured.
--Michael Sperberg-McQueen
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
On occasion, a large group of users in a particular area will suddenly vocalize what they feel we must support, because it's going to be the next buzzword. Or maybe it's an application area where Python is going to be really useful because the area involves a lot of tinkering and experimenting and prototyping before you get it right. A big example is XML.
Python has a lot of XML support, because at some point a lobby of people said XML is going to be big, and Python is such a good language for dealing with XML. They asked for standard XML support in Python's standard library, because they didn't want to depend on a third party. So I suggested they create a third-party XML support library for Python. It matured through several revisions of user testing, feedback, and improvement, and then became part of the standard library. And that is still growing. There are still some parts of XML that Python doesn't support, but there's third-party support that will eventually make its way into the standard library.
--Guido van Rossum
Read the rest in Designing with the Python Community
There are web sites that hold very strange data for me, because they insist that my phone number has to be 10 digits and my address has to have a two-letter "state" with a limited range of values.
Yesterday I used a web site that demanded I enter two phone numbers, that had to be different. So I invented one of them.
I've always been sceptical about validation. It encourages people to enter incorrect data in order to get it past incorrect rules. It's one of the things that gives computers a reputation for being inflexible.
--Michael Kay on the xml-dev mailing list, Friday, 21 Feb 2003
XML is like sex, even when it's bad it's still pretty good.
--Tim Bray
Read the rest in ongoing iTunes Music Store and the WWW
SOAP/XMLPP have created an incompatible subset of XML such that general-purpose XML generators cannot reliably be used to generate their messages, and general-purpose XML processors cannot reliably be used to receive them.
--Tim Bray on the www-tag mailing list, Tuesday, 01 Apr 2003
King Canute has always been a role model at the W3C.
--Arjun Ray on the xml-dev mailing list, Wed, 30 Apr 2003
I'm not crazy about the concept of universal devices. I think the way you serve people is by optimizing the functionality of whatever it is you're building. If you try to make something universal, it does not do any of those things very well. The carriers have gone just a little bit too far in trying to consolidate all these things into one gadget--telephones, PDAs, cameras, MP3 players. They've become so difficult to use and thus compromise the features.
--Martin Cooper
Read the rest in Tech News - CNET.com
As a budding animator I've had tons of offers from everyone to display my animations on their web sites, set up agreements where people would host or mirror my animations. Some of these people just want to co-opt my work for their own gain. These media dinosaurs don't seem to understand that I can own AND distribute my own content by myself. Why should I attempt to strengthen someone else's brand with my own work?
Although the recording industry needs a wake up call, artists can benefit themselves from not making bad agreements. The simplicity and stupidity of the Internet can keep artists from having to make more complex and limiting agreements with greedy third parties. Then the idea of a recording industry as we know it would be just as outdated as the media dinosaurs themselves.
--Chris Hill, Ubergeek
Read the rest in SuperVillain: He Has More Friends Now
It has become abundantly obvious that the Internet does not only consist of the browser. Now people are very actively using IM, music jukeboxes, video players, online games, alternative interfaces. While the browser is as important as ever, it's not the be-all end-all.
-- Kim Polese
Read the rest in Future: Is there life after the browser? | CNET News.com
When finally the imperialist capitalist states implode and we get in socialist lalaland, when people will no longer steal, or take a sick day to protest, when that great day has come, people will also create honest and accurate meta-data.
Until then, don't hold your breath.
--Berend de Boer on the xml-dev mailing list, Thursday, 24 Apr 2003
one of the things that appeals to me about things like XHTML and particularly XML is the fact that it gives you a great excuse to block people running Netscape 4 from even being allowed onto your site, whilst still proclaiming your holier-than-thou-W3C-standards-compliant credibility.
--Steve Sweeney-Turner on the XHTML-L mailing list, Thursday, 27 Mar 2003
Low-end media works best in most cases, and it's almost always considerably cheaper to implement than high-end media. So why do so many websites use inappropriately ornate media?
- Design agencies sometimes recommend more elaborate solutions than the client really needs in order to increase their billing.
- Technology vendors push whatever high-end technologies they happen to sell. Even though 3-D spinning and zooming rarely works as well as simple close-up photos, there is a vendor at every tradeshow selling 3-D to unsuspecting website managers.
- Website managers never watch people using their websites, so they make decisions without first-hand understanding of usability. Because advanced solutions seem better intuitively, those managers are easy prey for promoters of complexity.
--Jakob Neilsen
Read the rest in Low-End Media for User Empowerment (Alertbox April 2003)
there seems to be a persistent and growing misalignment between the dogmas of OOP and the realities of XML development. The WHOLE POINT of XML is to *break* the encapsulation of data behind interface methods, thus allowing interoperability at the data level rather than the object or API level. Of course, specific applications can and probably should build abstractions of the data so that their programmers can think of the XML as "invoice" or "catalog entry" objects, but it's not at all clear that the implementation of these objects would be well-served by being abstracted away from the "under the hood" details of XML (and HTTP, etc.).
--Mike Champion on the xml-dev mailing list, Monday, 16 Sep 2002
Does anybody really believe that XML is just UnicodeWithAngleBrackets, or is that hyperbole? For instance, does anyone really think it is an error for us to discuss an XML document using terms from the XML 1.0 specification such as elements, attributes, children, etc? These really do seem to strongly imply an interpretation of those characters into structures that can form a hierarchy.
Here's a view that I might call the "Only Structure" view: XML, like any language, has a surface syntax and associated semantics. "Unicode With Angle Brackets" describes the surface syntax, and the BNF in the XML Recommendation tells how to parse this syntax and what structures it expresses. The labelled structures expressed by an XML document are the semantics of the document.
--Jonathan Robie on the xml-dev mailing list, Thursday, 27 Feb 2003
For a one-shot application (ie. startup; process one document instance; terminate) the classloading overhead for the DOM API can be quite significant even with the most recent VMs. In some work I've done lately I've seen DOM classloading account for as much as 10% of wall clock time with the Sun 1.4.1_02 VM on Linux, Solaris and the other one. SAX, being a much smaller API, is at an advantage here.
--Miles Sabin on the xml-dev mailing list, Saturday, 19 Apr 2003
It's beginning to look like people have finally figured out the browser ought to be a browser, and if you need other tools, you can build other tools. Instead of trying to make the browser a Swiss Army knife, why not get a screwdriver and a wrench and other tools designed for the job?
--Barry Parr
Read the rest in Future: Is there life after the browser? | CNET News.com
I have yet to encounter, in 21 years in the software business, any program-level facility, whether it be SAX events, DOM trees, SQL APIs, POSIX, you name it, that offers the interoperability you get by exchanging XML messages. If your SOAP messages are unicode characters with angle brackets, they're likely very interoperable. If not, not. The only documented way to interchange any of these constructs at the moment is streams of text with embedded markup, and this is as it should be. What you do in the privacy of your sandbox is entirely up to you, but don't pretend that it's XML and don't pretend that it's interoperable. The only really interoperable APIs are those that are defined by a single implementation, e.g. Win32 and Apache APR and so on. XML exists to get us out from under that rock.
--Tim Bray on the xml-dev mailing list, Thursday, 05 Dec 2002
Object serializations are a very useful and common technique in programming. Object serialization can be accommodated on top of unicode-with-angle-brackets without discommoding anyone AS LONG AS BOXED XML does not shove the object-serialization world-view down everyone's throats.
Those of us who do not wish to treat XML exclusively as a serialization notation for objects are concerned that adding strong data typing, yada, yada into BOXED XML basically facilitates programmers in thinking of XML as serialization technology. It isn't, wasn't and shouldn't be allowed to become a serialization technology.
--Sean McGrath on the xml-dev mailing list, Saturday, 18 Jan 2003
XML is human readable. I can open the iTunes Music Library.xml file, and INSTANTLY I know the format of that file. Using NSDictionary, I can write a program to display that information in like 3 hours (and I'm fairly novice). Compare that to before, without XML. How often do you see old reverse engineered file specs start off with "This first int has to be 9202 or the file won't work. Don't ask us why, it is just that way."
--Steven Canfield
Read the rest in NSLog(); - Deatherage Drivel on X's "Open Formats"
What if we had kept the Web open rather than having a zillion proprietary extensions from companies like Microsoft? Wouldn't a standards-compliant Web be a better place?. We have a sick market--an unhealthy market--because most of the Web is browsed with a single vendor's browser. That's not a free market. A free market would have genuine competition. A free market would never have allowed a single vendor to become so dominant.
--Bruce Perens
Read the rest in Upstarts: Evolution creates second wave | CNET News.com
I get a particular charge out of seeing XML used in applications for which SGML was proposed, in the late 1980s and early 1990s, but usually rejected out of hand as hopelessly impractical. XML for configuration files (in Gnome, or Cocoon, or a zillion other packages); XML for graphics (SVG rules!); XML for programming (XSLT has become one of my favorite programming tools)
--Michael Sperberg-McQueen
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
it would be hard to predict now what kinds of libraries might be needed in a hundred years. Presumably many libraries will be for domains that don't even exist yet. If SETI@home works, for example, we'll need libraries for communicating with aliens. Unless of course they are sufficiently advanced that they already communicate in XML.
--Paul Graham
Read the rest in The Hundred-Year Language
We've never believed that Microsoft would truly make their XML format interoperable. Standard operating procedure with standards seems to be embrace, extend and exterminate. Despite the hype from their public relations department, I've seen no reason to believe that they would act any differently with XML.
--Gregg Nicholas
Read the rest in Microsoft limits XML in Office 2003 | CNET News.com
From the beginning, there was a question whether Microsoft was going to buy in completely to XML. Microsoft is often trying to spin their message, and they want to appear as if they buy into (open) standards. But they always put in the proprietary hooks somewhere in the final release of the product.
--Bob Sutherland
Read the rest in Microsoft limits XML in Office 2003 | CNET News.com
I always thought the <?xml-stylesheet?> processing instruction was a bad idea anyway, data should not define its own presentation rules even indirectly.
--Michael Kay on the xml-dev mailing list, Thursday, 2 May 2002
One example of an API design I found unsatisfactory is the DOM API for dealing with XML. That originally started in the Java world. I'm not sure if the problems with it are the same in the Java version as they are in the Python version. I have a feeling that the Python translation of the DOM API was actually done by sticking too closely to the Java version, and thereby being unpythonic, which is a completely undefined term.
--Guido van Rossum
Read the rest in Designing with the Python Community
In the long run, I think it's easier to make a URNs retrievable than it is to make HTTP URLs permanent, and that the W3C should stop trying to make an anti-URN policy.
--Larry Masinter on the www-tag mailing list, Tuesday, 8 Apr 2003
The trouble with schemas (i.e. schemas that don't support some notion of variation or phase, i.e. everything except perhaps Schematron and DTDs) is that they provide no real support for information items in the important class "this may be interesting to someone, especially a human, but we are not promising what format it has, which locations it can go into, and we don't want to commit that future revisions of even the current version of our software will keep this item, and we probably don't want to document it either: caveat emptor"
As someone else mentioned, as a schema progresses, then it becomes clearer which information items should have been first class (elements and attributes). But "comment conventions" (and PIs) say "we think this is bathwater: if you think you can find babies, be it on your own head."
--Rick Jelliffe on the xml-dev mailing list, Thursday, 6 Mar 2003
One reason XSLT seems especially mysterious, I think, is because people think of a stylesheet as a "program" that gets "executed". It's not: it's just a *specification* for a transformation, and rightly should contain the minimum possible programming logic. Mike Kay (or the guys at IBM, or MS, or your other friendly XSLT engine developer) wrote the program; I'm just running their code with my inputs.
--Wendell Piez on the xsl-list mailing list, Friday, 14 Feb 2003
I remember the day we started XML; it's hard to believe we are now celebrating its fifth anniversary. XML took the planet by surprise, and the news today is that there is no news when two different software platforms use open-standard XML to exchange data seamlessly over the Internet.
--Jean Paoli, Microsoft
Read the rest in XML makes its mark - Tech News - CNET.com
SGML was designed to make life easier for users, while XML was designed to make life easier for developers. Fortunately, it turned out that when developers are happy, they write lots of software, and that ends up making users happy as well.
--David Megginson on the xml-dev mailing list, Sunday, 16 Feb 2003
I see XForms in particular as crucial to keeping the Web from being eaten by the Web Services and "Rich Internet Applications" that have been eating around its edges for a while. The Web has to move forward if it hopes to survive, as its promise of cheap interoperability (which it did remarkably well, even with the Browser Wars) is under assault once more from vendors who have a lot to gain by fragmenting the Web and Web applications into proprietary pieces under their control.
--Simon St.Laurent on the XHTML-L mailing list, Tuesday, 19 Nov 2002
It's worth noting that XML by itself does not do nearly as much as some people (mostly in marketing, I hope) have said. It doesn't solve all the problems of data exchange and data reusability: you still have to make the data rich enough to be worth exchanging and reusing. To tag data richly, you still have to know the data. Tagging 'everything that could be of interest' is still impossible (not just impractical, but impossible). All XML does is get some extraneous difficulties out of the way of solving those problems. It allows you to avoid tying the data tightly to a specific hardware or software platform. It allows you to tag what you think is interesting, rather than what seemed interesting to the programmers who work for your word-processor vendor. Compared with other approaches, which add to the difficulties instead of reducing them, that's a win.
--Michael Sperberg-McQueen
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
The "Desperate Perl Hacker" argument was a bogus claim for XML 1.0 because of the existence of entities and CDATA sections but is quite farcical now with the existence of the Namespaces in XML recommendation (and it's bastard spawn "QNames in content").
--Dare Obasanjo on the xml-dev mailing list, Friday, 28 Mar 2003
The notion that there is an "XML data model" is silly and unsupported by real-world evidence. The definition of XML is syntactic: the "Infoset" is an afterthought and in any case is far indeed from being a data model specification that a programmer could work with. Empirical evidence: I can point to a handful of different popular XML-in-Java APIs each of which has its own data model and each of which works. So why would you think that there's a data model there to build a language around?
--Tim Bray
Read the rest in ongoing--XML Is Too Hard For Programmers
I don't think URLs should be used as namespace URIs at all. It opens up cans of semantic worms, as we have seen. I reckon namespaces should have been restricted to being URNs alone, but weren't because most people don't know how to get hold of URNs. Using URLs for namespaces was a quick hack to avoid having to go to the effort of making it easier to get URNs, and the price is being paid with user confusion and flamewars about what namespace URLs should resolve to.
--Alaric B. Snell on the xml-dev mailing list, Thursday, 20 Mar 2003
when you nest one XML document inside another, you should nest it directly, without using CDATA. XML is specifically designed to allow such nesting. CDATA is saying "the angle brackets in here may look like markup, but they aren't". So if they are markup, why put them in CDATA?
--Michael Kay on the xsl-list mailing list, Friday, 7 Mar 2003
XLink is too complicated for the truly simple stuff and too [limited? / naive? / attribute-twisted? / URI-blinded?] for the harder stuff. From my perspective, it's a good clean miss of any 80/20 point whatsoever.
--Simon St.Laurent on the xml-dev mailing list, Monday, 6 Jan 2003
The presentation of a table is typically 2-dimensional. And paper and CRT screens work well for 2-dimensional presentation. And markup languages let you express data in a 2-dimensional way. And quite often this is really useful.
But I suspect that the power and convenience of the available tools for entering and presenting 2-dimensional data lead us to use this model even when a higher-dimensional model would be more suitable. The use of cells spanning rows or columns is a sign that the data is bursting the seams of the 2-dimensional model.
--Terrence Enger on the docbook mailing list, Thursday, 20 Mar 2003
XML is not a prescription for peace with the Muslim world. But respectful attention to allowing other countries and individuals to develop and flourish in the ways they choose surely is necessary and, God willing, sufficient. Standards for the WWW need to be made with this respect and care built-in, and everyone involved in XML's specification should feel proud of its internationalization.
--Rick Jelliffe
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?"
--Mike Godwin
Read the rest in The Free Network Project
the slithering vermin who extort licenses of bogus patents have just heard that this is the Year of XML and are going after XML vendors rather than .coms or telcos or whoever they tried to leech off last year. Dealing with parasites is simply the price one pays for success. I guess it's better than having to deal with vultures, which is the price of failure.
--Mike Champion on the xml-dev mailing list
While some folks will deny it, so called XML industry evolved from and still revolves around XML-DEV. Yes, it's full of whiners and arcane discussions sometimes, but that is just part of XML-DEV. OASIS is guilty of taking advantage of notoriety around XML-DEV to boost its own reputation and then let it rot like a ghetto.
XML-DEV is not a mailing list. XML-DEV is a group of people who, over many years, have formed bonds, mutual respects, and learned to depend on each other. XML-DEV defines part of what each of us are for XML is and has been an important part of our professional lives. And what has OASIS have done for XML-DEV? Yahoo Porn groups get better service than XML-DEV.
--Don Park on the xml-dev mailing list, Wed, 12 Mar 2003
Any HTTP client can retrieve data from Amazon, eBay, or any other Web site, whereas a Web service client can only retrieve data from the subset of all Web services which expose the interface(s) it recognizes.
--Mark Baker on the xml-dev mailing list, Tuesday, 11 Mar 2003
Developers are being forced away from SOAP RPC because vendors are killing it off. (I just looked at the XMLP and WSDL WG membereships to confirm, and they are clearly dominated by ISV's who develop SOAP/WSDL products, rather than developers who use such products.)
--Rich Salz on the xml-dist-app mailing list, Friday, 07 Mar 2003
document creators who assume that consumers of their documents will be using all of the same ancillary technologies as they themselves (e.g. WXS) create informationally impoverished documents. If our goal is to insure the widest variety of the most useful documents, best practice demands that the syntactic text be the whole of it. If because you as author can delegate to a schema significant semantics which would otherwise be expressed in attributes or other inherent document content, you limit, if not preclude, some unexpected but valuable uses which I might make of your documents downstream. Every additional ancillary technology which you use effectively transforms your documents from what I understand as XML to something which is not 'my' XML, at least until I join in the proliferation and match your latest escalation.
--W. E. Perry on the XML DEV mailing list, Thursday, 27 Feb 2003
I have long been wary of W3C XML Schemas, and to some extent of XML itself. A jumble of companies and groups with divergent interests and backgrounds cobbled together the W3C XML Schema specification by throwing in a little bit of everything each party wanted, creating a typical committee-designed, difficult-to-understand standard. In fact, I have so many reservations that I generally recommend sticking with DTDs for validation needs, and filling any gaps strictly at an application level.
--David Mertz
Read the rest in developerWorks: XML zone : XML Matters: Kicking back with RELAX NG, Part 1
Code first, then specify. Anticipatory specs for problems people haven't tried to solve yet are just wild, random shots in the dark; at best, they waste everyone's time, and at worst, they cause confusion and hostility. Most existing XML-related specs should not have been written yet: we don't need a spec to cover X until many, many people have been trying to implement X for a while and have discovered where a common spec might be beneficial. A new field of development shouldn't *start* with a spec; it should *end* with one.
--David Megginson on the xml-dev mailing list, Sunday, 27 Oct 2002
The very nature of XSLT development is vastly different than, say, Java development. While some shops may use XSLT extensively, I doubt that you'll ever see very many XSLT equivalents of the canonical 100,000 line Java enterprise system.
(The DocBook XSLT stylesheets come close at 69KLOC, which is quite impressive. To be fair, though, there's a lot of repetition there, and most XML vocabularies I've styled with XSLT aren't nearly as large, nor do they need to target as many outputs.)
--Adam Turoff on the xsl-list mailing list, Thursday, 6 Mar 2003
Life in the markup world used to be a lot woolier. We lived in caves carved out of ancient brick and mortar, ate consultants half cooked over a fire of burning DoD contracts, carried spears made of left-over dedicated word processors and dipped in DSR poison, wore the skins of our marketing staffs, and met once a year in Boston to celebrate the summer solstice with the local SGML Wiccans. We collected coffee cups from CALS contractors who traded them for the arcane incantations to invoke the Internet gods to command telnet demons to fetch an RFP from a bulletin board. We abused WYSIWYGers and sat in council huts debating the uselessness of modeling document structures in relational tables, all to the beat of the drums of The SGML Way (whatever happened to that band? one hit and pooof.. gone from the charts).
Life was short and brutal. Standards were long and brutal. Trips to DC were just brutal.
Things are better now. Where are my anti-psychotics?
--Claude L (Len) Bullard on the xml-dev mailing list, Wed, 5 Mar 2003
My experience has been that many interop problems are a result of various stacks (ours included) trying to mask the existence of XML altogether. That combined with a WSDL specification (1.1) that invented far more than it needed to has made life harder than would otherwise be necessary.
--Don Box, Microsoft, on the xml-dev mailing list, Sunday, 9 Feb 2003
I wonder how many people that try to shoot down XML have ever had to hand write a parser for complex data transfers that use arbitrary data models. One parser bug can ruin your whole project.
--Doug Royer on the xml-dev mailing list, Monday, 03 Mar 2003
CORBA is a distributed-object framework that lets you create disparate components that discover each other and interoperate over a network. CORBA can also be used in other ways, but its primary purpose was to be a foundation for distributed objects. In other words, CORBA not only contains all the necessary features to build interacting components that discover one another, but also the features one needs for network-security issues. Put yet another way, CORBA is Web-services done right - it simply doesn't do it over port 80.
--Nicholas Petreley
Read the rest in KDE 3.1 vs. GNOME 2.2: How GNOME became LAME - Feb 28, 2003
In most projects, accessibility has fairly low priority because project managers underestimate the number of people who are impacted by design problems. They think that they are just losing a handful of customers, whereas in fact they may be turning away millions of customers, especially among senior citizens, who constitute a big and rich group that's getting more and more active online.
--Jakob Nielsen
Read the rest in Reality Check for Web Design
But the recording industry has a story of, "We do two really important roles. One is to make music available and the other is to compensate artists." But one of the things we know is that 80 percent of all of the music ever released isn't for sale anywhere in the world. And another thing we know is that 97 percent of the artists signed to a recording contract earn less than $600 per year off of it. So Napster doesn't have a better track record at compensating artists, but it sure as shit had a better track record of making music available.
--Cory Doctorow
Read the rest in O'Reilly Network: Cory Doctorow's Bitchun' World: P2P Gone Wild [Feb. 27, 2003]
When Jon Bosak approached me at SGML '96 with the challenge to write an XML parser in three weeks (because so it was written as a requirement in one of the first XML drafts) I was actually able to do it. Now, that we have dozens of layers added to it, you need an engineering department for the same task. Sometimes, to the innocent bystander, XML's complexity has just gotten out of control. The good news is, however, that tools and infrastructure increasingly absorb some of this complexity which allows us to keep going.
--Norbert Mikula
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
XSD is being driven principally by Microsoft, because it is a critical first stage to Post Schema Validated Infosets (PSVI), which in turn is a way to deal with XML as binary objects. X# is on the horizon, and it will likely be the next logical stage of that - loading an XML entity will create a data-aware class that can be treated as a first class citizen in a binary format (and which can also conveniently get away from all of those pesky openness requirements that XML in its current form exposes).
--Kurt Cagle on the xsl-list mailing list, Wed, 19 Feb 2003
Interoperability is the key to XML's success -- let's keep it that way: say 'no' to subsets, profiles and alternative formats.
--Henry S. Thompson
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
We knew XML could be a universal solvent for electronic data, but what's been exciting is watching it be used in new ways we hadn't even thought of at the time. Much of the initial adoption of XML has been in support roles rather than being a visible Web publishing phenomenon; application integration messages and B2B transactions are meant to be consumed by machines, not eyeballs. These uses of XML may not seem exciting, but they have increased the pace and quality of commerce in ways we couldn't have expected five years ago. Even directly on the Web, however, technologies such as graphics and multimedia have benefited from XML specifications such as SVG and SMIL, since these open specifications have allowed for greater choice and more competition.
--Eve Maler
Read the rest in XML makes its mark - Tech News - CNET.com
The primary benefits of XML are its widespread, CONSISTENT usage which allows for the availability of several off-the-shelf tools and reduces vendor lockin. Encouraging consumers of XML to support ill-formed XML reduces the power of XML and induces fragmentation. If we arbitrarily pick bits and pieces of a standard to support then we cheapen the technology and reduce it to worthlessness. I'd hate to see XML on the 'web reduced to HTML during the browser wars with people simply checking if "it works well with Mark Pilgrim's program" or creating ill-formed markup simply to satisfy broken tools.
--Dare Obasanjo
Read the rest in XML.com: This Article is Quite Depressing
Now that 'database' data and 'word-processing' data can both be processed in the same format, we have opportunities which we never have had before. I have heard too many document-oriented people whining about the horrible things the database people have done to XML -- imagine! They have forced the development of datatypes other than NAME, NUMBER, NMTOKEN, and CDATA for attributes! And I've heard too many database people complaining that the document people don't know enough about database theory -- imagine, the XML spec doesn't say whether an empty element has no content, or has the empty string as its content! How am I supposed to map that to a relational column with NULLs?
Be cool, guys. It's all information, and it's all information your users want to have access to in the same place. Document designers have been wanting better datatypes for years, and with every revision the SQL spec has migrated further from the purely relational model and closer to the directed-graph model of XML. Don't try to split them apart again, just to avoid having to deal with 'those people.' Learn to live together; you might come to enjoy it."
--Michael Sperberg-McQueen
Read the rest in XML.com: XML at Five [Feb. 12, 2003]
The bare minimum requirements for a non-validating XML parser are unambiguous and hardly onerous. I'm tired of people making gross generalizations and using them as excuses for nonconformance, as if the complexity of the XML rec approached that of WXS.
--Evan Lenz on the xml-dev mailing list, Friday, 21 Feb 2003
SOAP is using XML because of the lingering hype wave from XML, not because XML itself is particularly well-suited to the tasks that SOAP performs. I'd say SOAP used HTTP early on for similar reasons, and I hope that just as SOAP appears to be leaving HTTP behind as it becomes clearer that SOAP and HTTP have little to do with each other, that SOAP may yet leave XML behind.
--Simon St.Laurent on the xml-dev mailing list, Thursday, 04 Jul 2002
Keep in mind, the same guy that provided Reagan his "plausible deniability" and the "creative solutions for Iran/Contra" that got him convicted of perjury now runs the Total Information Awareness program for DARPA. And he loves XML. Whether we like it or not, we are all making his job easier.
--Claude L (Len) Bullard on the XML-DEV mailing list, Wed, 19 Feb 2003
XML was created to be a foundational technology, and in that goal it has far surpassed the expectations of those of us who were there at the beginning. Everyone knew that we were creating something that would simplify the development of applications and the management of information, but no one knew how far it would really go. Five years later, we still don't know. XML has spread its reach into almost every industry, and it's just continuing to expand out from there. Virtually every type of structured content or data collection worth representing has been, or is currently being, developed as XML. Millions of people use XML every day, and most important, many of them don't even know it. This is only going to increase as XML matures and becomes the enabling technology for Web services and single-source publishing.
--Tom Maglieri, Corel
Read the rest in XML makes its mark - Tech News - CNET.com
Special mention must be reserved for a single, simple design mistake that caused huge usability problems for the users in our study: unconverted PDF files. These files were especially troublesome when they were used to post an entire employee handbook or other massive document on the intranet in a single unnavigable and overwhelming mass.
PDF is great for printing. And it's fine to have printable documents available on the intranet, which saves distribution costs and gives employees instant access to print out whatever they need. But don't take the lazy way out and just stick a PDF handbook on the intranet; give users other options for accessing the information as well. Search, navigation, and online reading are all enhanced when you convert content into well-designed intranet pages, each containing a meaningful chunk of information about a specific topic with cross-reference links to related material.
--Jakob Nielsen
Read the rest in Intranet Usability: The Trillion - Dollar Question (Alertbox Nov. 2002)
We always figured there'd be a much more sophisticated way of navigating, but no one ever came up with it. Things like the Back and forward button, we never intended that to be a permanent part of the interface. But people get locked into metaphors. You have to be careful with the metaphors you put in front of people because once they click onto one, that's it.
--Marc Andreesen
Read the rest in Wired News: Conversation With Marc Andreessen
Applications that depends on a PSVI must agree not only on the choice of schema language but also on the choice of mechanism to locate the schema. As has been pointed out, xsi:schemaLocation is just hint; there is no single way that is mandated for an application to locate a schema. XML Schema does not specify a single way to get from a URI specifying a document to a PSVI; it only specifies the way to get to a PSVI from a URI specifying a document together with a mapping from namespace URIs to schema locations.
--James Clark on the www-tag mailing list, Monday, 17 Jun 2002
HTTP was designed for a class of applications. Other applications which have very similar requirements for latency, transaction semantics, security, error recovery, communication of options, client and server capabilities, etc., might well fit as "reasonable" to layer on top of HTTP.
Unfortunately, most of the applications that layer on top of HTTP are, unfortunately, very much unlike the application that HTTP was designed for, and have very different requirements for security, transaction semantics, error recovery, etc. etc.
--Larry Masinter on the www-tag mailing list, Friday, 7 Feb 2003
In the past five years, XML has gone from an obscure format for technical manuals to a central part not just of the World Wide Web but of modern computing and business. Applications of XML range from configuration files through to remote procedure calls, from desktop menu definitions to chat protocols. With every new usage of XML, the value of all the interoperable XML tools, both proprietary and open source, is increased.
--Liam Quinn, W3C
Read the rest in XML makes its mark - Tech News - CNET.com
The five years since XML was released have seen XML become the lingua franca of the Web. But this universal embrace has not always been accompanied by a clear understanding of what XML can and cannot do.
What XML cannot do is to magically solve the problem of data interoperability. XML just provides a framework within which interested groups can work out agreements about the vocabularies and data structures to be used in a given domain. The widespread adoption of XML has created a wonderful infrastructure of standardized tools and products to support the creation and implementation of such agreements, but deep down, the job of semantic definition requires the same grinding committee work that standards groups have been engaged in for more than a century.
On the other hand, there is relatively little awareness of one big thing that XML can do: It can play an essential role in freeing users from the big-vendor hegemony that has ruled the computer industry for the last 50 years. The ability of user communities to develop their own data formats is a powerful force for freedom from vendor control.
--Jon Bosak, Sun Microsystems
Read the rest in XML makes its mark - Tech News - CNET.com
Happy birthday XML! The past five years have really borne fruit for XML and some of its most important applications, especially Web services. The dramatic uptake of standardized ways of representing information has had a significant impact on the way companies think about the information they produce and the applications they share. Part of the evidence of this influence is that, as analysts who now completely focus on XML and Web services and the way they are changing enterprise architectures, we have spoken with more than 500 software vendors and end users--none of which now thinks that producing data in proprietary formats or with proprietary interfaces is tenable in the long term. The pervasiveness and widespread adoption of XML has in fact changed the economics of technology adoption--while in the past it might have been economically feasible to work in a vendor-proprietary, closed environment, the reverse is now the case. It is less risky and more cost-effective to adopt open standards for connecting companies and systems. As this trend continues, XML promises to be as ubiquitous as TCP/IP.
--Ron Schmelzer
Read the rest in XML makes its mark - Tech News - CNET.com
Pinpointing XML's influence is a hard challenge. How has the phone influenced you? XML is everywhere, and indeed that is what is amazing about it. XML is how we create Web content, how we integrate computers, how we define vocabularies and languages for communicating between companies and how we package those messages. It is also in our databases and how we get data into and out of those databases. My non-XML friends always say the most important thing about XML is that it is everywhere.
--Dave Hollander
Read the rest in XML makes its mark - Tech News - CNET.com
the issue is not whether validation (against XML Schema or any other schema language) is useful, but whether it's useful for that validation to change/augment the information that you get about the XML document within the transformation.
--Jeni Tennison on the xsl-list mailing list, Wed, 5 Feb 2003
SGML allowed extensive syntactic abbreviation, and SGML failed; XML forbade it, and XML succeeded. That's not the only reason that SGML failed, of course, but it was a contributing factor (SGML tools were just too hard to write, and markup errors were often too hard to locate and fix).
--David Megginson on the xml-dev mailing list, Friday, 17 Jan 2003
semantic laxness rather than rigor is essential to make URIs work. Basically, I'm happy with a humpty dumpty view of URIs: the agent making the reference and the agent interpreting the reference can basically allow URIs to mean whatever solves their problems. This implies a many-to-many relationship between URIs and things.
--Uche Ogbuji on the xml-dev mailing list, Thursday, 23 Jan 2003
I used to wallow in conceptual filth and complexity in the false belief that hard work could lead to redemption. The horror of dealing with namespaces in DOM caused me to pledge my soul to Occam, and accept Pareto as my personal savior :~)
--Mike Champion on the xml-dev mailing list, Saturday, 20 Jul 2002
The strength and flexibility of REST comes from the pervasive use of URIs. This point cannot be over-emphasized. When the Web was invented it had three components: HTML, which was about the worst markup language of its day (other than being simple); HTTP, which was the most primitive protocol of its day (other than being simple), and URIs (then called URLs), which were the only generalized, universal naming and addressing mechanism in use on the Internet. Why did the Web succeed? Not because of HTML and not because of HTTP. Those standards were merely shells for URIs.
--Paul Prescod
Read the rest in XML.com: REST and the Real World [Feb. 20, 2002]
There is no such thing as a "Resource".
URIs don't Identify anything on their own. Other technologies (RDF, XMLNS, HTTP, etc.) *use* URIs to Identify things. The nature of the thing Identified depends on who's doing the Identification.
If we dispose of the inconvenient fiction of a "Resource", most of the metaphysical hooey surrounding URIs goes away.
--Joe English on the xml-dev mailing list, Thursday, 23 Jan 2003
There are people in the RDF camp who think that to gain acceptance RDF needs to grow and become richer. On the contrary: I think RDF is where SGML was in 1996, i.e. proven to be a good idea but not widely implemented because ordinary people couldn't figure it out. What RDF needs is the equivalent of XML, a brutal reduction (at least at the syntax level) that hits 80/20 points and anybody can figure out in 15 minutes by looking at it.
--Tim Bray on the xml-dev mailing list, Friday, 15 Nov 2002
the beauty and appeal of truly Web-based loosely-coupled services is that they don't require marketechture, paradigm buy-in, venture capitalist mindshare, first-mover advantage nor any of the host of horrors of dot commieism. They can be built (as some of us routinely do) without compromise using simple generic tools on the "Web as We Know It" today. It is instead the malignantly-named Web Services which require a priori agreements and intimate mutual knowledge between sender and receiver which are anathema to the 'web'.
--W. E. Perry on the XML DEV mailing list, Friday, 31 Jan 2003
I offer an opinion. The relationship between URIs and things is many to many. One URI will be used to denote many things. A thing will be denoted by many URIs.
I offer a rationale for this opinion. It's preferable to constrain the relationship to one to many, as this results in simpler, deterministic software. However I believe the notion that a URI only ever identifies one thing, however appealing, is fictitious, and an shackle on the semantic web that will lead to unscalable systems and fringe benefits, in much the same way backlinking sidelined hypertext until the web was invented without the backlinking constraint. the many to one relationship will not hold, nor is manageable across the number of authorities the web encapsulates, leading to ambiguous and outright inconsistent data sets shared across a gloabl system that is by definition not architected to be resilient to inconsistency. Hence I encourage to TAG to advise the relationship is many to many.
--Bill de hÓra on the www-tag mailing list
Definitely, the more one has to discover services on the fly and late-bind to them, the more the principles of the Web As We Know it (such as hyperlinks, the ability to leverage Google, ...) will be important for Web services people to use and appreciate. A lot of the disconnect between the "Web as We Know It" folks and the "Web services" folks is that "discovered-on-the-fly, loosely-coupled services invoked over the Web" exist mostly in marketechtures and white papers now. The SOAP/WSDL/RPC paradigm works pretty well (at least compared to the easily available alternatives) for application integration on secure, highspeed LANs, and the people actually doing that stuff resist being lectured to by RESTifarians.
Some interesting dialogues are going to take place when people start working in the fuzzy middle where services must be loosely connected to each other yet tightly integrated with exisiting back-end systems. IMHO, neither the pure "design everything as a resource and access representations over the Web" nor the pure "design everything as an object and pretend the Web isn't there" approaches will suffice, so they'll have to cross-pollinate each other.
--Mike Champion on the xml-dev mailing list, Thursday, 30 Jan 2003
Between the last essay and now, the Supreme Court also decided the Eldred case, saying that Congress has unlimited power to extend copyright, thus making the limit of the "limited duration" unlimited.
This is Mancur Olson territory, where the effort required by the many to police the predations of the few is so high that special interests carry the day. For the average Congressperson, the argument is simple: copyright is a palatable tax that transfers wealth from the many to the few, and the few are better donors than the many. When the primary advantage of repealing that tax is something as unpredictable as cultural innovation, its not hard to see where to vote.
The Eldred decision costs us a shortcut. This will now be a protracted fight.
--Clay Shirky on the nec mailing list, Tuesday, 21 Jan 2003
The axis against Microsoft, certainly rooted in the carriers but with the Japanese CE companies starting to make overtures there, is looking more toward open-source solutions, so Opera is between the rock of Microsoft and the hard space of open source.
--Ross Rubin, eMarketer
Read the rest in Was Mac Opera gored on Safari? - Tech News - CNET.com
News flash: XML not invented as a serialization syntax for binary objects. Details at 11.
--Norman Walsh on the xml-dev mailing list, Sunday, 19 Jan 2003
Before the DOM, we had Netscape-flavored JavaScript and MSIE-flavored JavaScript. *That* was the problem that the DOM tries to solve.
There were and are plenty of language-specific APIs for SGML/XML processing, and none of them need to interoperate with each other. This isn't something that the W3C needs to standardize IMO.
--Joe English on the xml-dev mailing list, Friday, 20 Sep 2002
My taxes pay the bills for the government to protect your copyright. Under the regime specified by the Founders, that was an exchange: The state protected your copyright for a limited time and, in return, your work eventually passed into the public domain. Under Eldred, works may never again pass into the public domain, should the legislature so choose.
What Eldred is about is the theft-by-lobbying from the American people of intellectual property which had been promised to the public domain in exchange for time-limited protection.
--John Adams on the Computer Book Publishing mailing list, Thursday, 16 Jan 2003
I get nervous when programming language experts set out to fix what's wrong with XML. Markup is supposed to save us from people like that. :-)
--Claude L (Len) Bullard on the xml-dev mailing list, Monday, 6 Jan 2003
Mixed content is the very meat of natural languages, and for that matter of poetry, whether the admixture is of verbal time, aspect, or mood. Perhaps the most fascinating characteristic of the variety in human language is the myriad ways in which they deal idiosyncratically--but deal beyond a doubt--with the mixed content of human syntax, semantics, and ultimately communication.
--W. E. Perry on the XML DEV mailing list, Thursday, 16 Jan 2003
"Markup" is information that you add to a text document in order to delimit, contain, or define the borders of certain content. If you want to indicate that some text within an outline or in an article should be treated as a heading, wrap it with <h1> or one of the other heading tags. The same goes for quotes, addresses, lists and list items, and more. The markup isn't part of the content, it just sits alongside, marking the content up into specific chunks. You can think of it as an overlay, like a transparent sheet showing political boundaries lying atop a picture of the Earth from orbit. The artificial boundaries change everything, and yet they don't really exist in the physical world.
--Steven Champeon
Read the rest in The Secret Life of Markup
Maybe the browser wars aren't over, after all.
Last June, Netscape's expedition into the land of open source bore fruit in the form of Mozilla 1.0, a Web browser that arguably unseated Microsoft Corp.'s Internet Explorer--certainly not in popularity, but in overall excellence. At this week's MacWorld Expo, however, Apple Computer Inc. launched a Web browsing salvo of its own, called Safari, along with a reminder that there's still plenty of room for innovation in this space.
--Jason Brooks
Read the rest in Scoping Out Apple's Safari
There are no "SGML vendors", they have all styled themselves "XML vendors".
Many of them still support SGML, they just don't advertise SGML support. XML won't kill SGML unless it mutates in such a way that tool vendors can't support both XML and SGML from the same code base. If that happens they will, probably reluctantly, drop support for their oldest customers. Unless that happens, a lot of software will be silently SGML capable.
--B. Tommie Usdin on the xml-dev mailing list, Monday, 13 Jan 2003
It's time to get over the notion that a committee of experts can solve semantic problems for a wide range of problems. It was very nice of the W3C to provide a home for the simplification of SGML and give us a useful syntax, but the results since then have been hideous - and in large part because the world takes the W3C's pretensions seriously.
--Simon St.Laurent on the xml-dev mailing list, Monday, 30 Sep 2002
XML has succeeded for a bundle of reasons, while S-expressions have comprehensively failed (and I speak as someone who co-wrote a LISP, worked supporting TI Explorers which had LISP as its system language, and love eval and S-expressions.) Who can rule out that the things in XML not found in S-expressions helped it reach a critical mass?
--Rick Jelliffe on the xml-dev mailing list, Sunday, 12 Jan 2003
Scripts tend to do useful things, but in a way that's not obvious for machines to understand. I don't imagine a world where you could do everything in a nonscripting way, but it's very hard to know exactly what a script does. From the accessibility perspective, if everything is buried in a scripting language, then it's hard to find an alternative presentation of information. It's hard to repurpose the content.
--Ian Jacobs
Read the rest in W3C releases scripting standard, caveat - Tech News - CNET.com
Use the DOM the least you can. If you have an alternative technique to do exactly what you want without using the DOM, then use it. This technology will be more accessible, and it will be easier for someone else to read it.
--Philippe Le Hégaret, W3C DOM activity lead
Read the rest in W3C releases scripting standard, caveat - Tech News - CNET.com
Forget the idea that namespace names are URIs. There's a lot of wishful thinking in the spec that says using URIs for namespace names is a good idea, and indeed a lot of people do use namespace names that look like URIs, but the bottom line is that they are actually random character strings and they don't mean anything.
--Michael Kay on the xml-dev mailing list, Saturday, 14 Dec 2002
Where RPC protocols try as hard as possible to make the network look as if it is not there, REST requires you to design a network interface in terms of URIs and resources (increasingly XML resources). REST says: "network programming is different than desktop programming -- deal with it!" Whereas RPC interfaces encourage you to view incoming messages as method parameters to be passed directly and automatically to programs, REST requires a certain disconnect between the interface (which is REST-oriented) and the implementation (which is usually object-oriented).
--Paul Prescod
Read the rest in XML.com: REST and the Real World [Feb. 20, 2002]
Linking is such a fundemental component to information processing that it's surprising there isn't one universal method to link two pieces of information out there.
It's also rather bothersome that nearly every W3C WG needs to invent a form of hypertext to handle simple linking. Look at <xsl:include/> vs. <xsl:import/>; perhaps there's a need for both types of inclusion in XSLT, but why did WXS need to reinvent nearly the same thing with <xsd:include/> and <xsl:import/>? (And let's not get started on XHTML and HLink.) And let's not forget the bandage XInclude provides....
--Adam Turoff on the xml-dev mailing list, Monday, 6 Jan 2003
Applications that depend on a PSVI now require a very complex, heavy-weight schema validation process, rather than a relatively simple parsing process.
--James Clark on the www-tag mailing list, Monday, 17 Jun 2002
It sounds so easy. First, get a bunch of people together who share a common need to interchange some type of data - say, invoices. Explain XML to them. Explain the significant technical benefits of having an industry standard schema for invoices.
Get technically minded individuals into a room with plenty of whiteboards and caffeine. Sometime later they'll emerge with a consensus model of what it is to be an "invoice" enshrined in some schema language (UML/XML Schema/DTD/RelaxNG/whatever).
Thereafter, all interested parties use the schema for data interchange and all is sweetness and light.
This makes 100% technical sense but it often doesn't work in the real world. The reasons it doesn't work have nothing to do with flavors of schema language or indeed flavors of markup language. It often doesn't work because of soft issues concerning people.
--Sean McGrath
Read the rest in XML - Journal - Soft Issues Surrounding Industry Standard Schemas
For years vendors have been telling me "don't bother your pretty little head over the bits on the wire, just put the data in here and it will come out there." Except when it doesn't. Except when I have the audacity to use a programming language or operating system that doesn't have the library. Except when I don't have the budget to acquire the library. If there's a library there I'll cheerfully use it, but I want guaranteed access to my own data in an open format as a basic condition of being willing to play. I think I'm pretty well in line with the CIOs of the Global 2000 in my feelings on this; these guys are all covered in scars from the API wars.
--Tim Bray on the xml-dev mailing list, Friday, 06 Dec 2002
We've spent a lot of time trying to undo .NET vs. Web services. Web services are a technology. We implement in Web services. They implement in .NET.
It is confusing. .NET seems to be every bit of software Microsoft has created. When it started, it was focused, but it's widened to such an extent that it's hard to get a handle on it. When you deal with Microsoft and .NET from a development perspective, you're talking about building on a Windows platform. The world is not restricted to that. The importance of Web services is that you have to communicate. If Microsoft has standards and can't interoperate with COBOL, the company has failed. The whole spirit of Web services is the communications aspect and interoperability. You don't have to ask Web services what they're running.
--Robert S. Sutor, Director of e-business Standards Strategy, IBM
Read the rest in Fawcette.com - IBM, Java, and the Future of Web Services
Harry Potter's world resembles the world of computers in another way as well: In the Harry Potter books, the population consists of two distinct groups -- a small group of wizards, and a much larger group of Muggles (standard-issue humans) who know nothing about magic or the dealings of wizards.
Similarly, in our world, the vast majority of people don't understand computers or technology. Science fiction author Arthur C. Clarke once said that "any sufficiently advanced technology is indistinguishable from magic." Unfortunately, computers and the Internet are this "advanced technology" as far as most people are concerned. Things appear on their screens, computers deliver the desired results, and how it happens is all just so much magic.
In the Harry Potter books, the ethical wizards have agreed to leave the Muggles alone and not do magic tricks on them. It seems that computer wizards have something to learn from Harry Potter, because they often use their power in ways that are harmful to regular people.
I typically argue against poor Internet usability because it reduces a company's ability to generate business value from its website. Bad customer service equals fewer customers. However, the bigger picture is even worse: Every page that doesn't conform to expected behavior and design conventions undermines users' ability to build a conceptual model of the Web, and thus reduces their ability to use other sites with ease, confidence, and pleasure. Designers who inflict poor usability on the world and its Muggles are wicked wizards indeed.
--Jakob Nielsen
Read the rest in In the Future, We'll All Be Harry Potter (Alertbox Dec. 2002)
I don't think there are (many) people who want deliberately to obfuscate XML. The problem is that people believe it desirable to write specs before there's a proven need. That leads good, talented people into all kinds of wild guesses and bad decisions (sort of like Soviet-style central economic planning, which many Western countries imitated to varying degrees in the 1970's and early 1980's). This problem is not unique to the XML community.
--David Megginson on the xml-dev mailing list, Wed, 11 Dec 2002
Quotes in 2002 Quotes in 2001 Quotes in 2000 Quotes in 1999