The real question is why do people try to use HTML for a purpose for which older technology, like PDF, is more appropriate (I think it comes down to a failure of the owners of that technology to realise the need for internet links (limited use for commercial sites) and incremental loading soon enough, and that they failed to provide "free" entry level authoring tools - HTML originally could be hand coded by students and even now basic authoring tools are bundled).
--David Woolley on the www-style mailing list, Saturday, 28 Dec 2002
if you want to infuriate people who hate it when you're right, make sure you know the difference between "tags" and "elements" � tags are the things you insert into a document, that start with "<" or "</" and end with ">" or "/>" and start with the name of the element, known as an "identifier", such as "blockquote" or "p". Of these, only "start tags" may contain attributes and values. But you already knew that.
The combination of the start tag, content (possibly including other tags) and end tag is known as an "element". Now, you, too, can annoy people at geek parties.
For extra credit, sneer at those who use the term "tag" when they mean "attribute". Sophisticates may wish to also use the versatile Russian term nekulturny, and act as one might if confronted by a leper. This is a field rife with opportunity for snobbery. Try to be kind, or at least correct.
--Steven Champeon
Read the rest in The Secret Life of Markup
Layout and text formatting are distinct typesetting problems. Tables, for all their woes, are the only decent mechanism available for describing how things relate to each other in a columnar or grid-like way on a web page. "Clear" and "float" sound like bits of cork bobbing around a birdbath, which seems to be analogous to what happens when these attributes fail to work as intended. I�m going to guess that any mechanism that succeeds in solving this problem is going to be no prettier than tables.
--Franklin Einspruch on the www-style mailing list, Tuesday, 24 Dec 2002
XML has been, is now, and will continue to be a tremendous success. Its acceptance and implementation in various industries has been rapid and widespread. The number of implementations that conform to finalized Recommendations is large and growing, and other implementations come close to conformance.
Yet XML has strict syntactical requirements. How can this be? In fact, this is far from contradictory. The syntactical restrictions are a direct contributor to the success of XML. People and software do not pass junk as XML because the acceptance of junk is minimal among XML tools. The retention of restrictions on data is what encourages implementors to create and maintain XML software, knowing that lengthy error testing and recovery are not necessary.
--Etan Wexler on the CSS mailing list, Wed, 25 December 2002
Leadership is essentially like a fortune-teller scam. A fortune teller makes a bunch of guesses and hopes to get one right. In leadership, it's the same thing. You take over a big company, you reorganize it, merge a few things and then take credit for an upturn in the economy and say, "See what I did?" For some reason, that's legal.
--Scott Adams
Read the rest in Weasels rule, Scott Adams says
When I first heard about structured markup in the early 90s, people were already saying it wouldn't go anywhere because they had been hearing about it for years and it hadn't materialized: "Sounds Great Maybe Later." Later arrived.
When I first heard about Python in around 1997, it was already around 8 years old and yet hardly anyone had heard of it. Today, the level of Python awareness out there is much higher and still growing rapidly.
Other technologies that took decades to achieve "overnight success" include object oriented programming, Unix, hypertext and the Internet.
So I don't see any need to put a Best Before date on technologies.
--Paul Prescod on the xml-dev mailing list, Sunday, 10 Nov 2002
The PSVI is not XML; this is the most insidious problem. With something like default values, you can perform a normalization process and produce a self-contained document where defaults are explicit. The declaration of default values defines a mapping from an XML infoset to another instance of an XML infoset. It is not necessary to add complexity to applications to deal with default values. However, the W3C XML Schema PSVI is not like this; a PSVI is not an XML infoset. You cannot perform the PSVI infoset augmentation as a separate XML to XML transformation. All applications dealing with the PSVI are dealing with a different, more complex structure than applications that deal with pure XML. Applications communicating with the PSVI become much more tightly coupled: when applications communicate using the XML infoset, they do not have to share an address space, because there is a standard serialization of an XML infoset as XML, but this does not apply with the PSVI. I believe this is a catastrophic architectural mistake in XML Schema, and it needn't have been like this: schema infoset augmentation could and should be defined as an XML to XML transformation process.
--James Clark on the www-tag mailing list, Monday, 17 Jun 2002
C, C++, Java, etc. are very much tied to the concept of objects, components, functions, etc. XML and Web Services don't have these notions, so these existing languages, or the newer versions of the .Net languages need to evolve to capture the data manipulation aspects of XML and Web Services rather than the object/compiled aspects.
--Ron Schmelzer, ZapThink
Read the rest in Microsoft 'X#' On Tap?
Languages need to evolve or die. XML and Web services push data manipulation into mainstream programming. But current language substrates are optimized for objects, not data.
--Don Box
Read the rest in Microsoft 'X#' On Tap?
XML gives us a more dynamic, malleable way to accomplish this same goal, and so it has taken this pattern to a new level. This does not mean that OO is obsolete. On the contrary, OO now has a much richer companion to offer richer mechanisms for sharing coarse-grained state information. There are certainly situations where an OO solution is not called for. But that has always been the case, and OO systems still have a large role to play. The misguided thinking that the XML structures a system shares with the rest of the world must match the internal data structures used for processing is one of the things that leads naive developers to do things like try to use a 1GB XML document as a database. Encapsulation is still a good thing, but enlightened developers understand that in complex environments, different objects or systems may need to share coarse-grained data. The data that is shared is not simply the objects externalizing their internal data. Rather the shared data structures become part of the interface of the object, the contract it abides by in interacting with other systems. It may look quite different from what the objects use internally to support their processing needs.
OO was never a panacea, even though it has been hyped as such by some dogmatists. Today we hear from some dogmatists hyping XML as the panacea to replace OO. The truth is they are very nice complements to each other for any developer smart enough to avoid dogmatism and exercise common sense in choosing appropriate solutions.
--Michael Brennan on the xml-dev mailing list, Tuesday, 15 Jan 2002
The "cruft" that people complain of in RDF/XML is only there for relatively complex situations. For pretty simple uses such as RDDL or even HTML meta-tag equivalents, RDF can be as simple as you please.
--Uche Ogbuji on the xml-dev mailing list, Sunday, 17 Nov 2002
It is one of the recurring problems of W3C specification documents that WG members take it to mean what they intended it to mean while the other 5.9 billion or so humanoids on the planet (or those who take the time to read the document) have to go by why what was stated - however badly phrased or structured.
Apart from the fact that we no longer know what a URI is, a namespace is, a version number is we also have the delightful lack of clarity as to what is an XML 1.0 element. Oh for those halcyon simple days when production 39 of the February 1998 version of XML 1.0 said it all.
--Andrew Watt on the xml-dev mailing list, Friday, 25 Oct 2002
Google allows all sorts of useful queries that 5 years ago I thought would require the widespread adoption of XML and XML-based format standards (e.g., for resumes). Certainly many of the claims/proposals of metadata advocates 5 years ago look a bit shopworn in hindsight now that we see how well Google does by ignoring all (most?) metadata other than the linking patterns. Likewise (playing troll and jumping out from under one of my favorite bridges) the Semantic Web vision seems a lot less compelling after experiencing Google for a few years than it might in a Google-less world. Why invest in all that metadata when Google a) will ignore it anyway and b) does 80% of what the metadata would allow with ZERO additional effort by web authors/developers?
--Mike Champion on the xml-dev mailing list, Monday, 28 Oct 2002
In the short term, ease of development matters, especially for Web-based tools where lots of people still expect things to get done in "Internet time," whatever that was. Quick development cycles (typically aided by GUIs) and consistent results are key features here, and Flash can certainly provide those. XHTML+CSS+ECMAScript+XML+XSLT may not do that as consistently, thanks to browser variations and GUIs that tend to obscure as much as they help.
In the longer term, ease of maintenance is a much more important set of issues. Can generations of different development teams reuse the code they've been handed while writing in additional updates? How tightly bound are the data and the processes for working with that data? Can I collect information from different sources or send it out to different places? This was a Web application, but now we want to be able to access it from cell phones, PDAs, and CB radios.
Those longer-term issues are a lot more difficult to address, and they typically require a combination of technology capabilities and best practices. Spaghetti DHTML isn't going to have any maintenance advantages over spaghetti Flash, but a setup that uses XML as a foundation for XSLT transformations into a variety of different target media, including XHTML+CSS+ECMAScript (and possibly different versions of that) may well have an advantage over the long term over an application that uses XML or SOAP to communicate with a monolithic client.
--Simon St. Laurent
Read the rest in oreilly.com - - From the Editors List
One of the things about COM and CORBA is that you need both sides of the (transaction) handshake to understand each other. You don't need that in Web services. The notion that Web services is just the next step in the evolution of distributed object models is not quite accurate.
--David Litwack
Read the rest in Vision Series 3: David Litwack - Tech News - CNET.com
As a rule of thumb, avoid assuming that your XML data model ought to match your application's data structures. Such policies can sometimes be appropriate, but more often, your application's internal data structures were optimized for something unrelated to communicating with other applications. Most systems that automatically marshal and unmarshal data structures (maybe using "reflection" in Java) will make such assumptions; they lead to tightly coupled syustems. Tight coupling tends to cause fragility in the face of system evoluution, since upgrades normally occur incrementally on widely distributed systems (such as almost all web-based applications).
--David Brownell
Read the rest in SAX2 , O'Reilly & Associates, p. 99
XHTML 1.1 + SVG + MathML is not strictly conforming XHTML 1.1. I consider this is a serious problem: Again there's a gap between strict conformance and extensibility, even when using extensions described by the W3C. Ouch. This hurts.
--Christian Wolfgang Hujer on the www-html mailing list, Tuesday, 10 Dec 2002
Perhaps the world was lucky with TCP/IP and HTTP, that there was no commercial clamoring for products before the specs were mostly baked. The same, for good or bad, can not be said for XML.
Making mistakes is a necessary side-effect of developing new technologies. Inevitably, some of the XML technologies will be seen as mistakes, but it's only after implementation failures that these mistakes are seen, yielding better and more appropriate designs..
I'm sure this happened in the early days of TCP/IP, SMTP, escalator design, whatever ... -- but we didn't have the whole world (and companies with market capitalization well in excess of $100 billion) watching!
--Ian Graham on the XML Dev mailing list, Sunday, 8 Dec 2002
Thinking of (and sending around only) AngleBracketedUnicodeText might also help us to realize that it is not trees which we are streaming or otherwise passing between processes. A tree is constructed on the output of parsing at each processing node. Because the expertise and the intended function of each node will differ, there is no reason to assume that it is a goal, or even desirable, to construct at a receiving node the same tree which was 'serialized' by the sender.
--W. E. Perry on the XML DEV mailing list, Friday, 06 Dec 2002
Binary XML is a terrible idea that must be embraced before it does terrible damage.
--Sean McGrath
Read the rest in xml - dev - The privilege of XML parsing - Data types, binary XML and XML pipelines
There are some big companies who think that it's a good idea to store XML in relational databases. This means shredding your document, turning it into tuples, and then putting it back together again on retrieval. If you do this, you are going to lose fidelity. If you're using XML to represent simple tabular data, you probably don't care. If you're storing documents such as legal contracts, then you almost certainly do.
--Michael Kay, Software AG, on the xml-dev mailing list, Thursday, 5 Dec 2002
One standard API for all languages regardless of whether staticlly or dynamically typed, weakly or strongly typed, garbage collected or not is bound to be insufficient many cases. Add the fact that this API will have to ignore programming idioms, design patterns and naming conventions in most of its target languages since it will just pick one means that using it will be counter-intuitive from using other APIs in these target languages.
--Dare Obasanjo on the xml-dev mailing list, Sunday, 4 Aug 2002
what matters is what people actually do, not what spec writers invent or marketing departments announce support for. Initially no one made a big deal of announcing their support for SAX or RSS -- they just quietly used them. It was a decision made on the engineering level rather than the management level, so it actually mattered (and tended to solve real problems rather than hypothetical ones). Ditto for HTML in the early (pre-1994) days and TCP/IP even earlier.
--David Megginson on the xml-dev mailing list, Tuesday, 19 Nov 2002
The constraints that govern which elements and attributes can go where and what kind of values they can have are like fish, and the macros for giving names to hard-to-write data are like bicycles. Just because DTDs did both fish & bicycles we all kind of started to think that these kinds of things belonged together. But really, they don't. You wouldn't reasonably ask that your schema also functioned as your stylesheet, or your compression engine, or any number of other things; it's just far from obvious that funny-character-naming is a thing that a schema should do.
--Tim Bray on the xml-dev mailing list, Friday, 01 Nov 2002
Most current Web-based applications are ephemeral and must be immediately understandable or users will fail. Usability requirements for Web applications are far stricter than they ever were for traditional software.
--Jakob Nielsen
Read the rest in Flash and Web - Based Applications (Alertbox Nov. 2002)
I was a huge enthusiast of DOM at the beginning. I thought they got it exactly right using IDL for language-agnostic specification. But at that time my Zen of XML was pretty thin. As I've understood more deeply how XML is more than yet another data format for programmers to use, I've realized that the XML should inform the programming idiom, not the other way around. Given that I use Python for XML processing, and that Python is, regardless of any other value, a language rich in programming idioms, I realized that there were many very rich ways to process XML, and that DOM acted as something of a jail cell restricting me to one approach.
--Uche Ogbuji on the xml-dev mailing list, Sunday, 04 Aug 2002
Another reason Netscape gained market share is that they went and *hired* everybody who was working on open-source browsers to come and work for them instead :-) Just about the entire Mosaic development team, plus Lou Montulli (the author of Lynx) were early MCC employees.
--Joe English on the xml-dev mailing list, Friday, 22 Nov 2002
Once a product achieves over 90 percent market share, you'd think the competition would be over. That may be true in most markets, but in high technology, monopolies can fade if alternatives are free�and better. A lot of people have been switching their browsers from Internet Explorer to Mozilla 1.1, Opera 7, or even the new Netscape Navigator (now based on the Mozilla code). Count me in. For most of my browsing, I've moved from IE to Mozilla. The way I see it, Microsoft has simply dropped the ball, and there's no reason I should suffer for it.
--John C. Dvorak
Read the rest in Upstarts Attack Microsoft Slackers
As a graphic designer who has had numerous supervisory roles, I can say that many designers, especially those with print backgrounds, truly detest Flash because the interface for years was so awful (some people love it, of course, but for the life of me I can't say why). Today's version is really the first one that doesn't make me tear my hair out, and I'm awfully comfortable with just about any kind of interface. To carry on the grotesque mischaracterizations, I would compare Flash to McDonalds. Crappy product, but it's everywhere and you always know what you're getting. Someone could make an awful lot of money developing SVG (and XSL-FO for that matter) software designed with graphic designers in mind. If Adobe put in half the effort in SVG technology that Macromedia has put into Flash, SVG would stomp Flash into the ground within two years. Where's Thomas Knoll when we need him?
--Chuck White on the xml-dev mailing list, Saturday, 23 Nov 2002
XML is like a VW Jetta: environmentally sensitive, slow, dependable, and terminally uncool. Lasts a lifetime.
Flash is like a mid-80s Corvette: impressive but environmentally destructive. Oh sure, it gets you the chicks for a while, but ultimately most people sharing the road with you are thinking "what's *he* compensating for?"
--Nat Torkington
Read the rest in oreilly.com - - From the Editors List
I picture the Sem-Web in its current state of development as being like a bunch of 9 month old kids playing excitedly with Lego bricks. Some are excited because they have bricks to play with. Some are bickering because they think red bricks are inherently superior to green bricks or vice versa. Some are excited by their ability to join two bricks together. Some are particularly excited by the novelty of being able to push a brick halfway into the ear of their pet puppy. In time all of these excited kids will grow up and look back on this stage of semantic play as a piece of fun which doesn't represent mature thinking or behaviour.
--Andrew Watt on the xml-dev mailing list, Thursday, 21 Nov 2002
RDF doesn't *have* to be complicated, unfortunately, RDF all too often get's way too complicated and that's where sensible folks get thrown off the boat.
--Jonathan Borden on the xml-dev mailing list, Sunday, 17 Nov 2002
Compression is an interesting topic with a lot of engineering opportunities and tradeoffs, and this has a tendency to lead to over-engineering (in other words, you can impress your boss or get a PhD if you invent a new compression method, but you'll get much less recognition and no PhD if you just say that you don't think compression is necessary
--Martin Duerst on the www-tag mailing list, Tuesday, 15 Oct 2002
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
It is simply not the case that a non-validating parser is free to completely ignore the internal DTD subset. Certain parts of it, specifically ATTLIST declarations that provide defaults or non-CDATA attribute types, and internal ENTITY declarations, *must* be processed by all conforming XML parsers.
--John Cowan on the xml-dev mailing list, Thursday, 31 Oct 2002
XML is data, not objects. Understand this for it is the zen of XML.
--Dare Obasanjo on the xml-dev mailing list, Wed, 23 Oct 2002
It's hard to square "it's a usable set of types" with the fact that XQuery and XPath 2.0 are changing that set: xs:integer in W3C XML Schema is derived from xs:decimal; in the current WDs for XQuery and XPath 2.0 it seems to be being treated as a primitive type of its own. In W3C XML Schema, durations are covered by xs:duration; in the current WDs for XQuery and XPath 2.0 you have to use either xf:yearMonthDuration or xf:dayTimeDuration to get anything useful done, even when a general duration would be completely unambiguous.
If everyone could agree on a set of basic types then perhaps there would be weight behind the argument that 1 *is a* integer and can always be treated as such. The fact is that while isolated groups can reach an internal consensus about what a data type means, we don't seem to be able to get agreement between those groups. Given that, doesn't it make more sense to say "this application *treats* 1 *as if it were* an integer (as defined for that application)"?
--Jeni Tennison on the xml-dev mailing list, Saturday, 28 Sep 2002
My personal tourniquet at this point would just say that QNames should only be used to refer to element and attribute names. That would let XPath continue as is, and XPathish aspects of XPointer, but it would halt other uses of QNames.
Tourniquets do tend to cut off circulation to some parts, but they sometimes save a larger part.
--Simon St.Laurent on the xml-dev mailing list, Thursday, 14 Nov 2002
Sure, Netscape shot themselves in the foot with a total rewrite. But that rewrite is done now. The level of innovation in the Mozilla world is incredible.
--Paul Prescod
Read the rest in The Browser will Rise Again
Defining the syntax without the underlying data model *maximizes* interoperability because it reduces the number of shared assumptions. The notion that two organizations will share the data model for a purchase order or a bill of materials is just silly, but they can often deal with each others' serialized output. The evidence in the field is overwhelmingly on my side.
XML's lack of a data model is a deliberate, careful design decision, and the evidence of recent years is that it was correct.
--Tim Bray on the xml-dev mailing list, Tuesday, 08 Oct 2002
Process is poison. It looks good on paper, but in practice formal process doesn't work at all, at least not for initial spec development. XML 1.0 was developed mostly under the radar at the W3C; after that, it became very hard for the W3C to do any useful XML work (DOM and XSLT succeeded only because they were already well underway). Process is a good thing in a perverse way after a v.1 release, because it slows down work and postpones the usually-catastrophic v.2 release.
--David Megginson on the xml-dev mailing list, Sunday, 27 Oct 2002
If Corel's not giving away the next version, OpenOffice will. The idea is to commoditize the office apps, drive the price close to zero. It's very hard to make a profit on that basis.
--Jonathan Eunice, Illuminata
Read the rest in Does Corel's life jacket have a leak? - Tech News - CNET.com
Validation should be thought of a tool useful while manually manipulating XML documents, during development and for checking XML documents you get from sources you don't quite trust. In order to promote this point of view, it would help if validation was not as tightly integrated into XML parsing as it currently is (because DTDs define both physical and logical structure of the XML document), but rather seen as a separate step which *could* be integrated into the parser for pure efficiency reasons.
--J. Pietschmann on the xml-dev mailing list, Sunday, 27 Oct 2002
producing specs is much like producing software, or music. When individuals do it, primarily for intellectual satisfaction rather than to make money, then it comes out anywhere from brilliant to awful depending on the skills of the individual. And if it's awful then everyone ignores it. When corporations do it for commercial profit, then it comes out usable but mediocre.
--Michael Kay on the xml-dev mailing list, Monday, 28 Oct 2002
Somebody WILL popularize a a less awkward, less annoying, less funny-looking markup language. The only question is who and when... and whether it will be standardized or proprietary, patent encumbered or not, vendor-neutral or not. Innovation doesn't stop because it's inconvenient for the definers of the status quo. XML can evolve in the direction of being less "annoying" ... or it will be replaced by something that *is* less annoying whether we like it or not.
--Mike Champion on the xml-dev mailing list, Friday, 01 Nov 2002
Best practice is only now coming into XSLT. Unfortunately, documentation has not taken root as a big part of best practice yet, and I wish it would. But a lot of code gets rewritten because there's a lot of bad XSLT out there. I sure wrote my share of it early on. It's a very different language for a lot of people who work at the production level and aren't used to seeing it and don't have the time to study it. IT departments are throwing XSLT at their staff and saying "do this" and they are, but they're really winging it and learning it on the fly. It seems to take most places about a year to start getting it right. I mean, look at your average C++ developer who's building some app server stuff and then consider his or her reaction when handed an XSLT project for the first time. They'll hack their way through it, but they'll usually write some pretty funky code to do it, and nine times out of ten they'll drop in side effect scripting of some kind to get around perceived limitations in XSLT that often don't actually exist. I've seen it happen often enough to know that it's now what I expect to see when visiting someone else's source tree. But that really has more to do with bad IT management than the capabilities of XSLT. IT managers shouldn't force their current staff to crank out XSLT if their staff knows nothing about it. At least get them some kind of training.
--Chuck White on the xml-dev mailing list, Monday, 28 Oct 2002
I have yet to come across an XML system where the true performance bottleneck is XML parser speed. Moreover, the people I meet who are infatuated with parser speed are the same people who thought the Web would never work because HTTP was too slow or that Java would never succeed because it is too slow. Those old enough to have been there used to claim systems written in C rather than assembler would be too slow.
--Sean McGrath
Read the rest in XML is Too Slow...Not!
No more ligatures should be added to Unicode. Most of those that are already there, esp. the Arabic ligatures, should be deprecated. Ligature codepoints are totally unnecessary. They are counter to Unicode's character/glyph model. They fuck up important aspects of text processing such as sorting, searching and spellchecking. The only thing stupider than adding new ligatures to Unicode would be using Private Use Area codepoints for them, which super-fuck up text processing.
--John Hudson on the unicode mailing list, Tuesday, 29 Oct 2002
promoting XML is kinda like selling illegal drugs, where the first acronym is always free.
--Jeff Lowery on the xml-dev mailing list, Sunday, 27 Oct 2002
it took me some time to figure out what it was that I miss in XML editors. My grief is that most of those that do offer some help are focussed on schema-based approaches, which is great when you're editing documents that happen to have a schema, which in my case is less than 5% of the time. Most of the XML editing I do either has requirements very specific to a vocabulary (XSLT, XML Schema) or has to do with vocabularies which I later transform into their "standard" and verbose counterparts (eg DocBook). In such cases all I'd want would be to specify a CSS sheet -- perhaps with a limited number of extensions -- and get a nice wysiwyg IU for my document.
--Robin Berjon on the xml-dev mailing list, Monday, 28 Oct 2002
It is one of the recurring problems of W3C specification documents that WG members take it to mean what they intended it to mean while the other 5.9 billion or so humanoids on the planet (or those who take the time to read the document) have to go by why what was stated - however badly phrased or structured.
--Andrew Watt on the xml-dev mailing list, Friday, 25 Oct 2002
EDI isn't weird, it is actually very simple, it just looks terribly complicated. For a company wanting to sell EDI based software this is a godsend. The software is fairly trivial to put together, but because EDI looks hard to your average consumer, it is quite easy to convince them to part with lots of money, firstly to use the software, and secondly to have someone else set it up and maintain it for them. This gives the software vendor a nice, steady stream of recurring revenue for hardly any work.
XML has suffered from the problem of looking too simple to the user. Whilst this has helped uptake, users of XML expect to get it for free, or less. Fortunately a lot of people are putting a lot of effort into making XML seem as hard as EDI, and I think their efforts are beginning to pay off.
--Mark Seaborne on the xml-dev mailing list, Friday, 25 Oct 2002
Before we were in a stock bubble during the dot-com era. Now there's a weasel bubble. You know you're in a stock bubble when your cab driver starts giving you stock tips. The way you know you're in a weasel bubble is when historians are discovered to have made up history, ice skating judges fix the Olympics, priests are having more sex than you are. So sure, now is boom time for weasels.
--Scott Adams
Read the rest in Weasels rule, Scott Adams says
I think there are two basic mentalities to Web design. The first, and perhaps the majority, combines content and presentation into one product. The product is how the site is interpreted on a specific platform, usually the one the designer is using, like IE with default preferences on an 800x600 monitor. That IS the site and how it should look for everyone. The other mentality, perhaps the minority, understands that content and presentation are separate issues. The site IS the code. This code can be interpreted and rendered a plethora of ways depending on how individual users wish to do it from IE6 to PDAs to screen readers. Everyone gets the same or appropriate content and functions, but their presentation may vary, sometimes widely. Accessibility is just a by product of this approach. Doing things this way is just good design all around.
--Tom Kincaid on the WWWAC mailing list, Tuesday, 22 Oct 2002
Remember the golden rule - if you are using disable-output-escaping you are probably doing it wrong
--Andrew Welch on the xalan-j-users mailing list, Monday, 21 Oct 2002
XHTML 2.0, in my opinion, should use as many applicable existing XML standards as possible, and I don't see XLink as being too far out of the pale. It should be an XML version of HTML, not "our own homegrown way of doing things which are already done by other XML specs". The HLink proposal, as it currently stands, looks like exactly what it is -- a hack, and not a very good one.
--Kynn Bartlett on the XHTML-L mailing list, Wed, 25 Sep 2002
Just because a document is valid against one particular schema does not preclude it from being valid against another schema. Therefore the type of an element is not an *essential* part of the element, but rather a byproduct that's derived from using a particular schema with that element.
--Jeni Tennison on the xml-dev mailing list, Saturday, 28 Sep 2002
PDF docs are ideally suited to storage, and often are treated that way. PDF docs are also often used on the web somehow by people who aren't fussy about the fact that their screens are the wrong way up and that hard-wired burned-in columnar presentation for print involves much scrolling (or did until PDF 1.4 and it's wonderful reflow/tagging/structural aspect which enables my Pocket PC to make use of (some) PDFs in galley form).
--Ian Tindale on the xml-dev mailing list, Friday, 18 Oct 2002
Microsoft supported standards when it was the underdog. Everybody supports standards when they are the underdog. Sybase wants it to be as easy to migrate from Oracle to Sybase as possible!
It's when you are the market leader that standards become arguably optional.
--Paul Prescod on the xml-dev mailing list, Thursday, 17 Oct 2002
there's absolutely no need for the Java interface to be compatible with, say, the Perl or Python interfaces. A "language-neutral" specification doesn't help any, and can actually make things worse. Better to have customized APIs that better fit the language.
--Joe on the xml-dev mailing list, Friday, 20 Sep 2002
XML 1.1 has two themes: supporting users of minority and obsolete languages such as Sanskrit, and supporting user of minority and obsolete computers such as US-designed mainframes. Would you bet your own money on the success of such a venture?
--Michael Kay on the xml-dev mailing list, Wed, 24 Jul 2002
the OO/XML comparison breaks very early on for me because one is code and the other is data. Most applications don't have to worry about interacting with code (i.e. objects) from sources they have no control or foreknowledge off (unless you are building libraries) while on the other hand most applications have to handle data they receive from sources they have no control over. This is why most security bugs are due to bad data and not malicious code.
--Dare Obasanjo on the xml-dev mailing list, Thursday, 5 Sep 2002
It would be unfair to assume that every offshore Internet gambling firm is dishonest and untrustworthy. After all, just because so many of them are located in shadowy havens and use software whose legitimacy is utterly unknown, it's still possible that some of these guys are straight arrows.
For that matter, perhaps some of those spam e-mails offering you millions of bucks from Nigeria are on the level as well.
--Lauren Weinstein
Read the rest in Wired News: Online Gambling Laws a Good Bet
XML 1.0 demonstrated that it is in fact quite possible to enhance interoperability by doing much less, a lesson that appears to have gone completely over the head of the W3C.
--Simon St.Laurent on the xml-dev mailing list, Tuesday, 1 Oct 2002
in the real world, types are rarely mutually exclusive. (History and Biography overlap, a fact which most bookshops choose to overlook.) You can create a document that is both a valid XHTML document and a valid XSLT stylesheet.
--Michael Kay on the xml-dev mailing list, Monday, 28 Jan 2002
People always say they don't "get" extended links and then go right on to reinvent them. Right now, HTML authors build extended links using rickety prefabs of simple links and Javascripting. Even the HTML WG has sorta reinvented them in the new navigation links thingie (and possibly in other places). I think that almost any declarative approach to extended links would be easier for Web designers than figuring out what combination of iffy HTML and specialized scripting can be made to somewhat work in the variety of browsers.
--Uche Ogbuji on the xml-dev mailing list, Thursday, 19 Sep 2002
I don't believe there are any semantics that hold unconditionally for every application that might process a document. Editors, in particular, often treat documents in totally different ways than the processing expectations of a particular vocabulary might lead you to expect.
--Norman Walsh on the www-tag mailing list, Monday, 30 Sep 2002
Why do we have so many unusable things when we know how to make them usable? I think it has to do with the fact that the usability advocates don't understand business. Until they understand it and how products get made, we will have little progress. In the field of design, people come from three very different backgrounds. They come from art and architecture schools and they know how to make attractive things. Or they trained in computer science and psychology and they know how to make usable things but they don't know how to build anything, they're just good at finding flaws. Or they come from ethnography, and they are superb at understanding what people really need, but don't know how to translate that into products. So all this has to come together, otherwise no decent products will result. I've been trying to understand why usability people are left out of the game, and I think it's because they appear to have nothing to contribute.
--Donald Norman
Read the rest in New Scientist
I just "celebrated" my 5 year anniversary on the DOM working group, and supposedly the half-life of computer industry standards is about 5 years, so it is definitely time to start thinking about XML-API NG. The original DOM use case of cross-browser scripting is about dead (I hope Mozilla breathes life into it, but Microsoft doesn't have any interest anymore, and Dubya's antitrust folks don't exactly inspire fear of anything worse than a wrist slap if they don't play nicely with the rest of the industry). High-end scriptable XML authoring tools haven't exactly taken off, and with Word supposedly going to support any-schema XML editing Real Soon Now, I can't imagine anyone getting into that business. So, the basic idea of DOM as an abstract interface into a product's proprietary data structures may be falling by the wayside.
--Mike Champion on the xml-dev mailing list, Monday, 05 Aug 2002
this is something forgotten in many of the arguments and development cycles of recent technologies. The implementers are far fewer than the users. Ease of implementation, IMO, should take a back seat to ease of use. That something may take a software developer a few extra hours is no reason to make it harder for the author every document produced using that technology.
--Ann Navarro on the xml-dev mailing list, Saturday, 28 Sep 2002
Many people approach designs by asking, "What might the user want to do?" If you start with that question, the set of answers is infinite. You end up with interfaces that have 80 or 90 methods, or 50 or 60 interacting classes. Look at Swing's
JComponent
class, for example. It has well over 200 methods.JButton
, as aJComponent
subclass, inherits those methods. But someone dealing with a button cares about five of those 200-plus methods most of the time. The other methods are interesting in odd cases, so they should be set aside somewhere. But they're all in there together and you don't know what to touch.There is a phenomenon I call surface area of design, which is what you must understand about a design to know which part you care about. Does the fact that there are more than 200 methods mean anything to the
setText()
method? You must know something about those 200 methods to know the answer to that question. You have to know what to ignore. Many people say they don't need to look at all those other methods. But you do need to know if they will interact with the methods you do care about. The problem is you need to know enough about those other methods to know you don't need to understand them.
--Ken Arnold
Read the rest in Perfection and Simplicity
If I may indulge in horrid overgeneralization, there seem to be two kinds of XML projects: those where they send some emails and examples back and forth and are now in production, and those where they strike a task force to assemble the schemas, and the project is still in committee stage.
--Tim Bray on the xml-dev mailing list, Friday, 04 Oct 2002
Truth is that many developers / teams choose for XML as the communication language between various components of their application which they all write themselves. And why would you use validation in such a case ? You know perfectly well which XML is being generated ... it's not going to change overnight. One side on the app generates and the other side receives (and vice-versa) ... no need for a DTD or XSD.
--Gerben Rampaart on the xml-dev mailing list, Thursday, 3 Oct 2002
Notations are a poor cousin in XML because data attributes didn't make the cut for XML 1.0. Nobody in the XML world uses notations because (a) they don't know what to do with them, and (b) not much can be done with them anyway.
--Arjun Ray on the xml-dev mailing list, Thursday, 19 Sep 2002
Making websites more accessible can go beyond the benefits to people with disabilities. Accessibility measures also make good business sense. The Web is just as much a public space as our downtown office buildings and suburban shopping malls. By not being aware of, or taking the time to implement, common Web accessibility measures and guidelines, we are -- as website producers -- essentially hiding the elevators, ramps, handrails and wide doors which welcome anyone into our virtual buildings and help them find their way or move from place to place.
--Doug Bowman, Terra Lycos
Read the rest in Reality Check for Web Design
The Web is getting to feel like a science-fictional World of Clones with virtually no biodiversity, as almost all users have the same browser these days. It is still good practice to check that Web designs work on additional platforms beyond Internet Explorer and Windows, but the vast majority of users do use this combination. In any case, from an interaction design perspective, Netscape is a pale imitation of IE, and Macintosh is a higher-priced dolled-up variant of Windows. The differences between Web browsing platforms are like those between Indian and African elephants and not like the differences between crabs and eagles.
--Jakob Nielsen
Read the rest in Email Newsletter Usability (Alertbox Sept. 2002)
some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels. You've built a marvelous palace but the foundation is a mess.��Instead of��a nice cement slab, you've got rubble down there. So the palace looks nice but occasionally the bathtub slides across the bathroom floor and you have no idea what's going on.
--Joel Spolsky
Read the rest in Joel on Software - Back to Basics
Four years ago, when we first approached the problem, it was my perception that the folks at the W3C weren't keen on any solution that wasn't pure XML 1.0 + Namespaces. It must be understood that, at the time, we didn't have the wealth of experience that we now have with pure XML + Namespaces -not- being the panacea for all the world's problems.
--Ben Trafford on the xml-dev mailing list, Friday, 27 Sep 2002
part of the problem here is the mixing of requirements between people who want to represent the relationships between different resources (see them as a set of resources) and those who want to represent the traversal between them (see them as ends of a link). XLink ended up doing both and, as I think is usual in cases where a technology tries to do two things at once, ends up being not particularly well suited for people who only want to do one and not the other.
--Jeni Tennison on the www-tag mailing list, Friday, 27 Sep 2002
RPC over HTTP breaks architectural principles of the Web that were first described in 1996.
--Paul Prescod on the www-tag mailing list, Monday, 25 Mar 2002
If xhtml is supposed to be a replacement or follow-on to more or less replace html, then its hyperlinks MUST BE SIMPLE TO UNDERSTAND AND USE. Or at least, ordinary everyday hyperlinks must be. Otherwise this new facility will not get used, or it will be used wrongly and sour the majority of web page developers on using it - back to html 4.0, at least it works and we can understand it.
--Thomas B. Passin on the xml-dev mailing list, Tuesday, 17 Sep 2002
W3C Process froze XML at 1.0, while there was still unfinished business. For instance, what parts of the WebSGML TC did XML *take* (as opposed to being given)? Zippo. The #ALL keyword? Nope. The DATA declared value? Nope. IDN public IDs? Nope. And then the blunders. Mandatory SYSTEM identifiers? What a disaster. Why no special syntax (like say a reserved name, xmlid) for IDs when the way to declare IDs - a whole slew of ATTLIST declarations in the internal subset - were an obvious nonstarter? I could go on. Anyone who thinks XML syntax is pretty good hasn't run up on the rocks yet.
--Arjun Ray on the xml-dev mailing list, Wed, 18 Sep 2002
When I hear "semantic web" these days, I start to get the shakes, because it usually means somebody is going to do something horrible, like tie us to the namespace wrack.
--Jelks Cabaniss on the XHTML-L mailing list, Sunday, 22 Sep 2002
what got into the infoset was a purely arbitrary choice by yours truly, with an eye to SAX, DOM (much diminished later) and XPath. There is nothing normative about the selections, and saying "but it's in the infoset!" is no sort of reason why a parser ought to support something.
--John Cowan on the xml-dev mailing list, Sunday, 22 Sep 2002
Copy protection, like poor environment and chemical instability before it for books and works of art, looks to be a major impediment to preserving our cultural heritage.
--Dan Bricklin
Read the rest in Bit by bit, digital freedom disappears
Browsers -- in particular, JavaScript implementations in browsers -- are one area where the DOM makes the most sense. Here interoperability across multiple implementations is very important. (Also, the DOM, while supposedly "language-neutral", is actually heavily biased in favor of languages that support a certain type of object model, JavaScript being one such.)
--Joe English on the xml-dev mailing list, Friday, 20 Sep 2002
Let's say I'm Jo Schmo web designer, and I'm happy with what I've got -- a somewhat older (2 years or so) version of Dreamweaver, which is doing the job for me in letting me maintain my department's Web site.
Okay, someone comes along and tells me that I've got to validate. Validate, validate! Well, that takes me a little work (since it's not well-supported by my software), but I finally slog through using the W3C's validator and now I am producing legitimate, valid, HTML 4.01! Yay!
And this means... well, it doesn't seem to mean much of anything. The code's valid, but it worked before and it worked now. Even when invalid, I checked to make sure it worked in Netscape, IE, Mozilla, and even Opera. But now it is valid! Yay? So what! Are there suddenly a lot more people for whom it will suddenly work better? If so, I sure can't see 'em.
--Kynn Bartlett on the XHTML-L mailing list, Wed, 18 Sep 2002
I use XHTML for my personal sites, but I don't even consider using it for a project at work that I know will be edited later on by someone else. Why? Because I know that I can write the best-formed, prettiest XHTML around, and a few months later someone else who has been assigned to the project will go in with their font tags and uppercase editor-generated table tags and totally invalidate my code, and probably also post to some internal list (that I'm still on, damn it!) asking why on earth this MJI Brower person put all these weird slashes at the end of the <br> tags. :-)
--Molly Ives Brower on the XHTML-L mailing list, Wed, 18 Sep 2002
I have learned to be even more skeptical than before about the slew of APIs doing the rounds in the XML development community. An XML instance is just a documents, guys; you need to understand the document structure and document interchange choreography of your systems. Don't let some API get in the way of your understanding of XML systems at the document level. If you do, you run the risk becoming a slave to the APIs and hitting a wall when the APIs fail you.
--Sean McGrath
Read the rest in ITworld.com - XML IN PRACTICE - APIs Considered Harmful
Good design is disruptive. It upsets the status quo because (especially in North America), we are surrounded by shoddy products, ad hoc solutions, apathetic service, and half-baked plans. And a great many people, even if told their professional or personal lives could be better, prefer to muddle along with the various devils they know rather than undertake the effort to think or act in new ways.
--Matt Gushee on the xml-dev mailing list, Monday, 16 Sep 2002
Being able to selectively ignore the work of other W3C working groups as well as other groups within the computer industry when coming up with technologies seems to be an unwritten requirement for W3C working group membership.
--Dare Obasanjo on the xml-dev mailing list, Saturday, 14 Sep 2002
there is absolutely no rational and logical reason why dates and times, alone among all units of measure, should have found their way into XML Schema while other units have not. They certainly shouldn't have been defined as primitives, with a status that user-defined types can never aspire to. Too much SQL thinking by far.
--Michael Kay on the xml-dev mailing list, Monday, 5 Aug 2002
When we look out on the landscape, we don't see enough Web sites--and, in particular, customer-facing sites--that have XML Web services interfaces that people can take advantage of.
--Jim Allchin, Microsoft senior vice president for Windows
Read the rest in Microsoft exec's Web services blues
When people come to me saying "I want something to solve my business problem... and I want XML in it!" it's like somebody saying "I want you to build me a car... and I want you to use 5mm diameter bolts to assemble it!"
--Alaric B. Snell on the xxml-dev mailing list, Friday, 13 Sep 2002
Versioning is a can of worms. But what good is a can of worms if you never open it? :-)
--Norman Walsh on the www-tag mailing list, Wed, 11 Sep 2002
XML is not the ultimate answer -- it's the re-capitulation of the "hierarchical data" meme after 15 years of submergence under the "table" meme. It came in from the wilds, even though Microsoft in particular nurtured it and propagated it. Sure, people are trying to force-fit everything into XML, just as they did with the relational model 10-15 years ago, some of it makes sense and some of it doesn't. Some of it will succeed, and much of it won't ... and in 5 or 10 or 15 years some new meme will come in from the wild and displace the now-ossified XML. That is the Tao of Software.
--Mike Champion on the xml-dev mailing list, Tuesday, 05 Mar 2002
Another thing to keep in mind is that people will do stupid things. To you, everything you write is important. To the person using that design, it is a means to an end, and they want to understand as little of it as possible. As a result, you want to make illegal or improper things impossible. Any mistakes you can't make impossible, you want to catch. In other words, first design such that improper things can't even be written or expressed. They are impossible to do. Errors you can't make impossible, you want to catch right away. So as soon as a user makes a mistake he or she is told.
Don't give people a method that does something error-prone. Give them the method that allows them to do the subset that is not error-prone. Suppose you have a file object on which you can call open and close. You can only close an open file. You shouldn't be able to call close on the file object, because it may not be open. The open method should return something on which you can invoke close.
Therefore, you can't invoke close on something you have never opened, because the only thing you can invoke close on you get from open. Now you can't express the error. So you don't have to catch the error of attempting to close an unopened file, because you can't even write that.
--Ken Arnold
Read the rest in Perfection and Simplicity
There's going to be a cut-off point. I don't know when it's going to be, in the next version of the browsers or at some other time, but there will be a cut-off point. If we're going to move the Web to XML, we've got to move it.
--Ann Navarro
Read the rest in Language barriers on the Web?
DTD validation and XML Schema validation are not mutually exclusive. Sometimes authors might want to use some DTD features (e.g. entities) while taking advantage of the XML Schema validation.
--W3C HTML Working Group
Read the rest in XHTML 1.0 in XML Schema
HTML is dead. Web developers have to accept this and move on to XHTML.
--Uttam Narsu, Giga Information Group
Read the rest in Language barriers on the Web?
I personally ended up coming down against AF-style markup both for namespaces and for XLink because I thought you ended up with ugly, error-prone markup - among other things, in a Unicode environment, using white-space separated tokens is a recipe for interoperability problems. Also I hate hiding significant markup inside character data or attribute values (which is why I'm so irritated at the ubiquity of qnames in these places, but I long ago lost that argument).
--Tim Bray on the xml-dev mailing list, Tuesday, 13 Aug 2002
I was among the earliest implementors of XPath and XSLT. I thought, and still think that they were remarkably well-conceived languages. XPath and XSLT 2.0 are ruined by excess, and I'd be surprised if they supplant the 1.0 versions any time soon, as they are.
--Uche Ogbuji on the xml-dev mailing list, Saturday, 06 Jul 2002
The URL subset runs "the Web as we know it today", and URIs run "the Web as some folks think it might possibly be someday". URI advocates who claim the Web as proof that URIs work are grossly misleading at best.
--Simon St.Laurent on the xml-dev mailing list, Monday, 12 Aug 2002
The biggest problem with the W3C is the impression in industry that every XML technology must be either a W3C technology or blessed by it. The unfortunate side effect of this is that every W3C recommendation is treated as the ONE TRUE STANDARD (be it XML query, XML schema, XML protocols, etc) so every industry and academic interest group has to have a hand in creating what becomes a bloated, complex, special case ridden, internally and externally inconsistent standard which is then foisted upon the industry.
--Dare Obasanjo on the xml-dev mailing list, Sunday, 1 Sep 2002
The fact that Netscape 7.0 arrives hot on the heels of the similar but superior Mozilla 1.1 only serves to illuminate the small but significant differences between the two: Mozilla is highly customizable and offers a number of user options, while Netscape forces users to accept many features and functions they probably don't want while removing some they probably do.
--Jim Rapoza
Read the rest in Netscape 7.0 Shrivels Under Mozilla's Shadow
I think you should do 1.1 to allow unicode 3+ characters in names, but changing the white space rules is just gratuitous incompatibility that helps no one, not even users of NEL.
--David Carlisle on the xml-dev mailing list, Wed, 24 Jul 2002
anyone who write an XML Schema is certainly well advised to also have a schema-validating tool different from the one they are using for development and maintenance, just for the reason that implementations regularly differ. For contracts, specify that documents must validate against a schema, and specify at least two validators.
--Rick Jelliffe on the xml-dev mailing list, Wed, 24 Jul 2002
You seem pretty confident that the long term market of XML will favor sophisticated type systems and other data binding issues mixed into core XML processing. I predict that this approach will flop. We shall see, but I'll go one up on Sean McGrath's bet: if all this overgrown welter of "object XML" is still in serious play in 2006, and I show up at any XML conference, it will be in a tutu and an afro with a chin strap.
--Uche Ogbuji on the xml-dev mailing list, Saturday, 06 Jul 2002
Syntax pours a lot of concrete into airy abstractions, and even lets you ask tough question and expect a straight answer. While a lot of people seem more interested in ideas than syntax, control over syntax can be an enormous source of power.
--Simon St.Laurent on the xml-devg mailing list, 26 Apr 2002
It's a symptom of a weird problem that the markup community has suffered from way back into the SGML days - the irrational belief that schemas are somehow magic, that when you've designed a schema you've designed a language, and that schemas somehow have semantic import. This problem is still rife over at the W3C, as witness the people who insist on wiring schema dependencies into XQuery and the like. I've been ranting about this for a decade but it doesn't seem to do much good.
--Tim Bray on the xml-dev mailing list, Wed, 21 Aug 2002
I spent a year teaching introductory XML courses, and this Namespace URI thing was *always* the most difficult point for people to grasp. After the first time or two, I made a special effort to explain it as clearly as I possibly could. Well, some people got it, others didn't. Maybe something was lacking in my presentation skills, but I tend to think the notion of a string that looks like the target of a hyperlink but need not point to anything is inherently confusing.
--Matt Gushee on the xml-dev mailing list, Wed, 21 Aug 2002
XHTML 1.0 was designed as a bridge between HTML and XML. XHTML 2.0 is "the other side" of that bridge, dropping much of the deprecated content and moving forward into new, more "XML" methods of accomplishing tasks.
--Ann Navarro
Read the rest in Language barriers on the Web?
It may be okay for the browser to initially render the page with the designer's text size, but users should be able to easily enlarge text, no matter what the style sheet says. After all, it's my screen, my computer, and my software, and they should do what I say.
--Jakob Nielsen
Read the rest in Let Users Control Font Size (Alertbox Aug. 2002)
The web started with one and only one really good idea: "Let's make a universal namespace." HTML was crap (except for being easy to use and implement). HTTP was crap (except for being easy to use and implement). SOAP could be technically excellent or crap. Doesn't matter. It's survival characteristics will depend on the extent to which it acknowledges that the only thing that really, really, really matters is that universal namespace. As Cairo and Blackbird did not. Oh yeah, and it would help if it was easy to implement, which SOAP is not.
--Paul Prescod on the xml-dev mailing list, Friday, 15 Feb 2002
Microsoft exposes everything through XML because it is so much more open than Windows. Other players can walk in, extract data, and present it back to their users through a different set of applications, and make a nice living doing that.
--Dana Gardner, Aberdeen Group
Read the rest in Office bets on XML odds
Sometimes developers use quirks of HTML to improve layout, design, etc. XHTML doesn't tolerate deviations from the specification, making it a bit more rigid as well as complex. What will be the challenge for XHTML is getting HTML designers to think like programmers--not an easy task.
--Ronald Schmelzer, ZapThink
Read the rest in Language barriers on the Web?
the essential XQuery language -- extended by an update syntax with or without the W3C's blessing, and with the "type safety" stuff left to earn its own way in the world irrespective of the W3C's blessing -- should let us do integrations across document collections and across products and even storage paradigms, far more easily than we do now. Even the controversial overlap with XSLT could be a long- term strength if it allows ordinary SQL-trained developers to do straightforward XML data reformatting without having to wrap their heads around the recursive template processing design pattern. I honestly think that XQuery could do for XML what SQL did for the relational model -- put a single, general tool into the repertoire of mainstream developers that gives them a lot of power to deal with the new approach without having to wrestle with its bizarre details.
--Mike Champion on the xml-dev mailing list, Friday, 03 May 2002
I have realized over time that I missed the mark with HyperCard. I grew up in a box-centric culture at Apple. If I'd grown up in a network-centric culture, like Sunday, HyperCard might have been the first Web browser. My blind spot at Apple prevented me from making HyperCard the first Web browser.
--Bill Atkinson
Read the rest in HyperCard: What Could Have Been
What if they threw an XHTML 2.0 party and nobody came?
--Robert Gruber on the WWWAC mailing list, Tuesday, 13 Aug 2002
The big problem with XHTML 2.0 is that it's not backward compatible. And I don't see any killer feature that makes a site author say "I gotta have that."
--Uttam Narsu, Giga Information Group
Read the rest in Language barriers on the Web?
I'm not actively using or converting code to XHTML for the simple reason that virtually none of our partners or clients are remotely close to using XML technologies in their most important applications,. Since they are sticking to traditional J2EE and Windows DNA architectures, so will we. When more critical applications depend on XML technologies, I'm quite certain we will be using XHTML extensively. But there's a big difference between experimenting with new technologies for a pilot project and implementing a critical Web-based system for a client who expects nearly 100 percent uptime and virtually no bugs.
--Brian Schmidt
Read the rest in Language barriers on the Web?
Keep ISO 8879 alive. It is ISO that guarantees that markup is the property of the commons. XML was a coup to make it the property of a consortium and to bring it under the control of a self-appointed, self-selected group that now insists it knows best what the people need. It took a fight to keep it a proper subset of SGML, and those who think and still propose SGML "be stabbed in the back", are serious idiots, well-trained, but foolish, poltitcally and socially naive, and to be ignored.
--Claude L (Len) Bullard on the XML DEV mailing list, Friday, 2 Aug 2002
I think you shouldn't attempt to plumb the depths of the logic behind decisions made in the W3C management and W3C working groups - they are beyond your ken (and mine). Personally, I never find it useful to attribute sinister motives and complex machinations to groups of people - as a group, people are far too stupid to manage anything that complicated.
--Shane McCarron on the XHTML-L mailing list, Friday, 09 Aug 2002
CDATA sections should be removed from XML: they are ugly, not needed, and make parsing hard.
--Bert Bos on the www-html mailing list, Saturday, 10 Aug 2002
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
Markup is a skill in its own right, like research or expository writing, required, or at least very handy indeed in the expert practice of an increasing number of domains. Markup is a very different skill from programming. Like basic programming, basic markup can be taught on simple principles, but like skilled programmers skilled markup practitioners have refined and mastered techniques through repeatedly confronting problems which yield to an understanding of deep patterns.
--W. E. Perry on the XML DEV mailing list, Thursday, 01 Aug 2002
When you publish something on USENET, it is immediately available to anyone who subscribes to USENET. The medium is public -- anyone can publish into USENET. Web pages, by contrast, require you to publish to a privately-owned site, and require the reader to deliberately connect to your private site to consume what you published. In such a system, the metadata is only available to the person who can "crawl" for it. Push vs. Pull. Pull is ideal for the web, but push is ideal for semantic web.
--Joshua Allen on the xml-dev mailing list, Tuesday, 30 Jul 2002
Perhaps the most verdurous aspect of XML is the way it throws open the doors of the cathedral, inviting users to partake of the sacrament, much to the chagrin of the priests bowed before their hex-editors.
--Mike Haarman on the xml-dev mailing list, Thursday, 1 Aug 2002
Ceci n'est pas une représentation.
--John Cowan on the xml-dev mailing list, Thursday, 25 Jul 2002
Standards bodies work well when they see their task as the codification of best practices (look at the C standards org) versus when they consider themselves think-tanks (XML Schema, XQuery, C++, etc).
--Dare Obasanjo on the xml-dev mailing list, Wed, 24 Apr 2002
Solutions based on HTTP have not proven to be suitable replacements for USENET, for example. There are thousands of web-based discussion boards active, and they have some nice features. But they fail dismally in every respect that the semantic web cares about. In fact, I would say that the rise of web-based discussion boards has dealt a terrible blow to interoperability and opened the door for proprietary lockin. USENET is a *global* set of subject identifiers, with a basic protocol set that allows anyone to easily become a part of the global discussion space. If you and ten thousand other people write tools that publish to USENET, and I write a tool that gathers data from USENET, we all automatically work together, without needing to rent a bunch of HTTP servers or learn each other's proprietary interfaces.
--Joshua Allen on the xml-dev mailing list, Monday, 29 Jul 2002
The question of whether PIs should *ever* be used seems to be in process of resolution on the side of a resounding "no." My initial reaction to this was to bristle, because, for example, if PIs were supported in HTML we wouldn't have so much severely crufty executable-comment embedded languages about. Instead we'd have severely crufty PI embedded languages. Still, that's at least arguably an improvement. But for XML, because of its inherently extensible design (which indeed makes XML without some sort of extension no language at all), doesn't really need PIs, it just needs proper extension language (or "vocabulary" or "schema" or "dialect") design.
--Amelia A Lewis on the xml-dev mailing list, 27 Jul 2002
If you or I asked Congress for permission to legally hack other people's computers, we'd be laughed off Capitol Hill. Then we'd be investigated by the FBI and every other agency concerned with criminal violations of privacy and security.
Then again, you and I aren't part of the movie and music business. We aren't as powerful as an industry that knows no bounds in its paranoia and greed, a cartel that boasts enough money and public-relations talent to turn Congress into a marionette.
--Dan Gillmor
Read the rest in Mercury News | 07/28/2002 | Dan Gillmor: Hack...
Berman is opening the door to massive denial-of-service attacks against perceived pirates, without the attacker having to get prior authorization to launch the attack. This could have devastating effects on computers on the same network or in the line of fire. For instance, if everyone on your block has a cable modem, and someone is thought to be a pirate, a denial-of-service attack against that perceived pirate could take the entire neighborhood cable network down.
--Argus McNabb
Read the rest in The Dark Side of Hacking Bill
XHTML is an app, a reformulation of HTML as an application of XML. More simply, HTML never meant to be a language of design and interactivity. It was designed to create an opportunity for documents to be marked up properly and managed. But then for browsers to grow, we took that simplistic language and made it do backbends to accommodate presentational concerns. We ended up with complicated markups to produce visual results on a specific user agent known as a browser.
If you have one of today's browsers, it can read and interpret most of that HTML without a problem. But other types of agents have difficulty interpreting it. There's also the issue of accessability: the problems for folks with disabilities because of the overbearing use of nonstandard markup. The first goal is to separate the document structure from its presentation. In 1.1, the strict form does not allow for any kind of presentational markup such as borders, cell padding, colors, or fonts. Everything has to go in a stylesheet, with presentation separated from structure through stylesheets or multiple stylesheets. That way, you can get the same content to a Web browser, a screen reader, or a printer. Going back to no presentation in a markup document opens up possibilities.
--Molly Holzschlag
Read the rest in Web Builder Conference.
It's becoming impossible to set standards in multimedia; huge numbers of patents are granted. In Japan there are 4,000 patents on image and wavelet technology alone. It's followed the US model, where for many, many years, the US has allowed patents on very small changes to very detailed technical terms and where the benefits are few
--Richard Clark
Read the rest in The Register USA
today, even after the Internet bubble, the Internet hasn't ended. The Internet is actually reaching greater penetration rates. Usage is up. Page views are up. The only metric that's not up is valuation. But valuation is not a valid measure of impact on people's lives.
--Bill Gross
Read the rest in Ideas Aplenty From Idealab Head
JXTA's XML subset parser approach is wrong: after defining the minimal infoset they want to work with (a fine thing) and specifying the subset of XML that is meaningful given their infoset (another fine thing) they then take the step of implementing a parser for than particular set (a regretable step) and calling it XML (a bad step). Brand appropriation is confusing, but putting the cart before the horse (e.g. subsetting the syntax to suit a single infoset) goes against XML's basic approach.
--Rick Jelliffe on the xml-dev mailing list, Saturday, 27 Apr 2002
Changing namespaces is changing every named construct in the language. ie it's not a new version it is a completely different language. Sometimes the changes are so radical that that is what you want, but usually it is not what you want. This is the heart of the (in)famous three namespaces for XHTML debate.
--David Carlisle on the xml-dev mailing list, Thursday, 18 Jul 2002
The Namespace Rec simply adds the ability to have URI-syntax strings in element type names and attribute names without breaking SGML backward compatibility. It is pure syntax.
What you decide to *use* the capability for, if anything, is another matter.
--John Cowan on the xml-dev mailing list, Thursday, 18 Jul 2002
This would have been much simpler if the namespace rec has said informatively that namespace URIs were intended to be dereferenceable. It was obvious; it was noted; it was refuted and now it is becoming fact. I don't mind because it makes sense as long as one understands that this is an index and a control put into the content of the namespace. It is only rattling because the history of the XML crew seems to be one of asking others to look the other way while the knife changes hands. That is not exactly a web of trust.
--Claude L (Len) Bullard on the xml-dev mailing list, Thursday, 18 Jul 2002
A lot of PR emphasis will be given to the new and enhanced XML features, the latest in an aggressive, two-year campaign by the company to win over IT departments with massive "buzzword compliance." It's not clear whether even two percent of FileMaker's customers use these features or ever will, but the company evidently feels that its biggest threat is not being taken seriously as a database platform, and they're probably right about that. (I imagine all FileMaker developers have run into at least one IT professional who didn't know that FileMaker was a relational database environment or that it was available for Windows. The fact that anything is ever developed in Access is testament alone to widespread ignorance about FileMaker.) In any event, the XML features are no joke, and they hold the promise of increasingly ubiquitous connectivity between database systems without having to deal with ODBC drivers. (And what Mac database power user wouldn't like to say goodbye to ODBC drivers forever?) For the moment, though, developers should be somewhat concerned with a fairly long list of "known issues" for these feature as listed in the accompanying documentation.
--Jay S. Levin
Read the rest in FileMaker 6 - MacInTouch Reader Reports
I don't think you can graft static type-safety onto XSLT (or anything else) as an afterthought. If you want a language with static type-checking, you really need to design it in from the start: It drastically affects the design of the language. I think there's a place for both languages like XSLT and more strongly typed XML processing languages. I predict XQuery will become a very important example of the latter.
--James Clark
Read the rest in developerWorks: XML zone : Keeping pace with James Clark
In the world of the Harry Potter books, wizard parents teach their children "Never trust anything that appears intelligent if you don't know where it keeps its brain," because it may be powered by dark magic that can enslave you. The same advice might be given to those who are offered "smart" APIs and GUIs and frameworks that hide all those ugly URI, HTTP, and XML bits on the wire.
--Mike Champion on the xml-dev mailing list, Saturday, 27 Apr 2002
URNs are useful for the same reason that ISBNs, ISSNs, etc. are useful. They weren't intended to replace URLs; they were intended to cover a case for which DNS-based and protocol-based URLs have repeatedly been demonstrated to work poorly -- specifically, as identifiers which have a high probability of being stably bound to the same resource over very long periods of time (decades or more). The assumption is that for some purposes a stable association between the resource name and the resource is more important than being able to access that resource using that name from anywhere at any time.
--Keith Moore on the xml-dev mailing list, Wed, 17 Apr 2002 16
They don't have the right to grant permission for any link, and they in fact don't have the right to withdraw the right. The real problem is that NPR, a credible news agency, promulgates something that is utterly untrue. And that this chills speech. NPR owes the Internet an apology, not a minor revision to its policy
--Cory Doctorow
Read the rest in NPR Retreats, Link Stink Lingers
XML 1.0 did a wonderful job of saying "these are our goals" rather than "these are our use cases", and that actually worked. Now that the use cases are back on the scene with claims of "our customers want to do XYZ", the features are piling on.
--Simon St.Laurent on the xml-dev mailing list, 22 May 2002
the Namespaces in XML recommendation specifies a mechanism for disambiguating XML elements and attributes by attaching them to a unique name which for their purposes they chose the set of URIs. This was unfortunate in that these dissambiguating mechanisms became overloaded in that they are both unique names (namespace names) as well as locations and identifiers for resources on the Internet (the unfortunate namespace URIs as they are NOT called in the Namespaces in XML recommendation but in the ones that came after it like the XPath and XSLT RECs).
However since the Namespaces In XML recommendation considers http://www.25hoursaday.com different from http://WWW.25hoursaday.COM or http://12.228.162.249 while most if not all DNS systems do not. A namespace name is not necessarily interchangeable with a namespace URI.
--Dare Obasanjo on the www-tag mailing list, Monday, 1 Jul 2002
Generally-speaking, XPath 1.0 programming is a bit like reduced-instruction-set computing; there is not always an obvious solution, but there is usually a solution (the exception being general joins, and hence operations like "distinct").
--Michael Kay on the xml-dev mailing list, Monday, 8 Jul 2002
XML has many uses, but I feel a number of companies are using it just because it's the hot, new thing. Everything can't be stuffed into one type of structure. I think XML's strongest point is it's ability to allow different systems to share common data in a meaningful way. The standardization of the data makes programming the systems much easier. The organization aspect of XML is also nice, but one paradigm doesn't fit all. Some data structures are way too complex to be defined with XML.
--Ricky Bacon on the wwwac mailing list, Tuesday, 19 Mar 2002
the W3C was created by big businesses specifically to prevent their own marketing departments from destroying the value inherent in the Web through their own, and their competitors', short-sighted, quarterly-revenue-driven pursuit of profits. It was not created by academics. Open source developers actively opposed the creation of a pay-to-play consortium. The only reason it is at MIT is because that's what was needed to attract the people with a clue to an underpaid job.
--Roy T. Fielding on the xml-dev mailing list, Tuesday, 23 Apr 2002
What we're seeing with Web sites that are viewable only with IE is the privatization of the Web, and that's a dangerous setting. We're moving toward a world where all the capabilities of the Internet are reprocessed through a single filter, with Microsoft's business plan behind it.
--Mitchell Baker, Mozilla.org chief lizard wrangler
Read the rest in Sites bow to Microsoft's browser king
It just dawned on me one day, that I wanted control over what I was producing. What good is a video I can only watch with certain software because of patented restrictively licensed codecs? What good are my term papers locked in a proprietary dead format? What good is a website which can only be viewed properly by installing a particular browser from a particular vendor. Even if that vendor is giving me the right to use this browser for free now. For free is not freedom. You can't take this too seriously. How much control do I have when the only possible solution to a problem, must come from the sole vendor of a software product I have been trapped into using, or just used because that was what was available and I didn't know better, or even bought because it was the only solution to a particular problem.
--Marco Scoffier on the wwwac mailing list, Sunday, 2 Jun 2002
Any technology that is pressed into being all things to all people will soon evanesce into nothing useful for anyone.
If people just needed interop and tools, they didn't need to hijack XML for the purpose. Comma delimited files provide *all* the power of XML for relational and OO dumps with much fewer inefficiencies and much less cruft (CDATA sections, entities, etc.)
Again, we are here talking XML, not OO or relational systems. XML is a *text processing system*. My potted theory of why XML has gained so much sudden prominence in such a diversity of fields is that a lot of the weaknesses of the super-platonic approach to software design (i.e. relational and OO thinking) have been showing of late, and developers were initially amazed at how much more productive they could be with loosely-coupled systems based on XML.
It is my contention that a lot of very smart people have inexplicably missed the whole point of this felicity and are busy remaking XML into the tightly coupled, top-down structured system from which they were originally finding solace. This is a very bad thing, and this is why people like Simon and me are happy to just say the OO and relational folks are laying a cuckoo's egg in the nest of XML
--Uche Ogbuji on the xml-dev mailing list, Thursday, 04 Jul 2002
I'm willing to bet that WXS, XQuery, XPath 2 and the whole PSVI thing *will* be the subject of this pattern. The only other possibility - which is worse - it will be so complex that the only way to make it work is get all your tools from one supplier. Nice one.
I hereby offer to turn up at an XML conference in 2006 with a salmon steak and a bowl of petunias on my head if this stuff is not radically subsetted or simply ignored by large parts of the XML world in the medium term. The only other possibility is that it will only be available from a select number of vendors in which case I will not be involved in XML in 2006.
--Sean McGrath on the xml-dev mailing list, Thursday, 04 Jul 2002
SOAP is really a level 6 (presentation) protocol. Therefore it should ride on top of TCP and application protocols should ride on top of it. I have no confidence that this will happen, however, because moving SOAP to TCP will arguably slow deployment. After all, more programmers know how to work with CGI/servlets/ASP than with raw sockets. I expect that less "enlightened" SOAP vendors will see the marketing costs as outweighing the technical advantages that accrue from using Internet protocols as they were meant to be used.
--Paul Prescod on the www-tag mailing list, Wed, 15 May 2002
I'd like to look at the reality of the modern Web. Standards-compliant browsers with beautiful rendering, ADA section 508, the Internet Explorer monoculture under assault from Gecko and non-PC-form-factor devices, Web Services. I'd like them to conclude that the only sane, sensible, affordable way forward is to go standards-based on all their content.
--Tim Bray
Read the rest in Browsing Around for New Targets
Office 11 will have great XML support. I read that in all the major trade press write-ups. Well, yeah, OK. So what else is new? Three years ago, Microsoft claimed that Office 2000 had great XML support - and in fact, the XML support in O2000 ain't shabby at all. One year ago, Microsoft claimed that Office XP had great XML support - to the point of using XML as a native file format. Sorta. What makes the Office 11 XML support better than the previous versions' XML support? Durned if I know.
--Woody Leonhard on the Woody's Office Watch mailing list, Tuesday, 2 Jul 2002
I've never understood the distaste for DTDs. The only real eyesore is parameter entities. They function as grabbags for all the things that were missed in the first cut at the syntax - too few kinds of declarations and thus the brittle practice of using a text substitution mechanism to "capture" conceptual categories.
--Arjun Ray on the xml-dev mailing list, Thursday, 13 Jun 2002
In many of its recent attacks, Microsoft has argued that open source is bad for business, but you have to ask, "Whose business? Theirs, or yours?" The answer to that question is very different if you're an end user rather than a software vendor.
--Tim O'Reilly
Read the rest in O'Reilly Network: The Strange Case of the Disappearing Open Source Vendors
NPR still maintains that people who link to NPR's site require permission -- the new policy merely conditionally grants that permission.
I'll say it again: The most harmful lie you can tell about the Web is that permission is a prerequisite for linking. There is no copyright interest in controlling how people reference your work.
The most ironic thing about this is that NPR maintains that the rationale for it is to maintain "the highest journalistic ethics and standards." Journalism is about telling the comprehensive and accurate truth. Here we have NPR knowingly promulgating a destructive myth, something not borne out by copyright law or practice.
--Cory Doctorow
Read the rest in Boing Boing: A Directory of Wonderful Things
The resolvability issue strikes me as entirely artificial and an unfortunate artifact of having used URLs instead of URNs for namespaces. We don't talk about the "resolvability" of element type names or PI targets or notation names. Why should we talk about the "resolvability" of namespace names? These are *names* not *locations*, and its unfortunate that they look like locations.
--Ronald Bourret on the xml-dev mailing list, Tuesday, 09 Apr 2002
Honestly, what is the use case for software (or a user) to be able to put an empty tag in the document and have the value defaulted rather than just explicitly put the intended value into the document? This simply shifts a burden from the producer of a document to the consumer of the document; a producer can *force* a consumer to have to construct a PSVI (or have a hard-coded equivalent in application code) in order to reliably interpret the infoset of a document. If the default value is intended, why is it an unacceptable burden for the producer to just put the intended value in the document?
--Michael Brennan on the xml-dev mailing list, Thursday, 28 Mar 2002
a fundamental assumption of the URN architecture is that there cannot be any single resolution system for URNs - first, because there are too many parties who will insist on controlling it (this predated the whole IAHC / ICANN mess but we were trying to avoid the problems that would soon plague DNS); and second, because we didn't think that any set of resolution protocols was likely to last forever, so there would always be a possibility of multiple resolution protocols during transition periods even if not at other times. hence, URNs are pure names - by design they are fundamentally divorced from any association with a resolution protocol.
--Keith Moore on the xml-dev mailing list, Wed, 10 Apr 2002
S-expressions have been able to do what most of use XML for for decades. The primary benefit of XML is not the syntax nor any other technical reasons but the fact that for once most of the software industry is agreeing on a common data interchange format across all levels. One that satisfies the needs of the data heads, the document heads and the in-betweeners.
--Dare Obasanjo on the xml-dev mailing list, Friday, 21 Jun 2002
the fact that the WAP presentation language WML was very different from HTML has slowed the development of WAP applications. But it would be ridiculous to expect that this would have been different if the presentation language was HTML or XHTML. The point is that the particular ergonomics of the phone (screen size, navigation capabilities) forces developers to design an application specifically for WAP browsing. Even if the presentation language was HTML, there would still be a need for specific development for phones.
--Nicolas Lehuen on the xml-dev mailing list, Monday, 11 Mar 2002
The abysmally bad decision by the Librarian of Congress in the Internet radio royalties case is, quite simply, the end of almost all Net radio. It's another victory for the greed-mongers who control popular music in America, and the hell with the rest of us.
To claim this is anything but a disaster for a medium that had promised to provide an alternative to the absolute garbage on today's commercial radio is to deny reality. Cutting in half a royalty rate that would put Internet radio stations out of business immediately only means they'll go out of business slightly less quickly.
--Dan Gillmor
Read the rest in Silicon Valley
I don't like the way that REST is sometimes advocated, mostly because I hate it when people use the terminology that I created to explain this stuff as some sort of mandate for a particular architecture. The first three chapters of my dissertation clearly indicate why there is no such thing as a universal, best-fit architecture.
REST is an architectural style that models system behavior for network-based applications. When an application on the Web is implemented according to that style, it inherits the interconnectivity characteristics already present in the Web. REST's purpose is to describe the characteristics of the Web such that they can be used to maximum advantage -- it does not need to define them. REST isn't supposed to be a baseball bat; it is supposed to be a guide to understanding the design trade-offs, why they were made, and what properties we lose when an implementation violates them.
--Roy T. Fielding on the xml-dev mailing list, Friday, 26 Apr 2002
I used to think XML 1.0 was a complex spec with anomalies and spent a lot of time pointing them out. Then the scale of XML's sins was put to shame by those of W3C XML Schema. I don't think mere pointing is adequate.
--Simon St. Laurent on the xml-dev mailing list, Tuesday, 04 Jun 2002
I'm finding more and more people running into problems with using JAXP because of multiple implementations on the classpath (especially with 1.4), though, so at this point I recommend that people go directly to the parser rather than using JAXP unless they really and truly don't care what parser they end up with.
--Dennis Sosnoski on the jdom-interest mailing list, Wed, 19 Jun 2002
What I am saying, and I have yet to meet any users in the industrial publishing industry who disagrees, is that XML Schemas is deficient to the point of irrelevence for a large niche, and that the answer is not to bloat it but to build a schema language on a modular framework. I am only against XML Schemas to the extent that I am for plurality and richness; in other words, I am only opposed to XML Schemas to the extent that it is pushed as a universal schema language that cannot tolerate alternatives.
--Rick Jelliffe on the xml-dev mailing list, Saturday, 8 Jun 2002
The PSVI is not XML; this is the most insidious problem. With something like default values, you can perform a normalization process and produce a self-contained document where defaults are explicit. The declaration of default values defines a mapping from an XML infoset to another instance of an XML infoset. It is not necessary to add complexity to applications to deal with default values. However, the W3C XML Schema PSVI is not like this; a PSVI is not an XML infoset. You cannot perform the PSVI infoset augmentation as a separate XML to XML transformation. All applications dealing with the PSVI are dealing with a different, more complex structure than applications that deal with pure XML. Applications communicating with the PSVI become much more tightly coupled: when applications communicate using the XML infoset, they do not have to share an address space, because there is a standard serialization of an XML infoset as XML, but this does not apply with the PSVI. I believe this is a catastrophic architectural mistake in XML Schema, and it needn't have been like this: schema infoset augmentation could and should be defined as an XML to XML transformation process.
--James Clark on the www-tag mailing list, Monday, 17 Jun 2002
IMO, it is a bad thing for the meaning of a message (request or response) in a Web architecture friendly protocol, to depend on some information outside the message (like defaults). This is an issue for all protocols, but is especially important for XML protocols, due to XML-isms like external entities and the PSVI.
--Mark Baker on the www-tag mailing list, Thursday, 13 Jun 2002
To the extent that an instance is self-describing and self-contained, that's a win. Default values appear magically as a result of reading something else somewhere else. That's bad. Yes, defaults induced by DTDs are identical to, hence just as bad as, those from XML schemas.
--Tim Bray on the www-tag mailing list, Thursday, 13 Jun 2002
Every XML processor has to at least look at ATTLIST declarations in the internal subset so that it can do attribute defaulting. The external subset and other external parameter entities can be ignored completely, but not the internal subset.
--John Cowan on the dsdl-comments mailing list, Friday, 14 Jun 2002
middleware vendors have being resisting web technologies chomping away at their lunches for some time now, but it appears to be a losing battle.
--Bill de hóra on the xml-dev mailing list, Tuesday, 11 Jun 2002
XML, or rather the many subtle and diverse uses thereof, is getting far too complicated for me. I am going back to EDI. You know where you are with EDI; it looks horrible, but it is quite straight forward under the skin. XML is just the reverse; you get fooled into thinking, just nested angle brackets, how elegant, how simple; and then whoomph! some rascally person drops several tons of horrible complexity on your desk. Just so they can force you to buy expensive development tools, and a whole lot of other paraphernalia you never knew you needed, all to make it seem simple again.
--Mark Seaborne on the xml-dev mailing list, Tuesday, 11 Jun 2002
It's a long battle to convince people who are billing by the hour to change the way they work. We plan to lovingly guide our peers toward accessibility and standards compliance, and if that fails, we plan to guilt-trip them. And if that fails, we will ridicule them mercilessly, as we once ridiculed Netscape and Microsoft.
--Jeffrey Zeldman
Read the rest in Browsing Around for New Targets
Many (most?) off the shelf XML parsers, at least when validating, will by default attempt to retrieve external subsets and other entities via their system ids. This implies that an arbitrary XML document instance, whether from a trusted or untrusted source, can cause an XML processor to make network connections to any host on any port using any protocol for which retrieval is supported by the network client associated with the XML processor. This opens up at least two, possibly more, kinds of attack
--Miles Sabin on the xml-dev mailing list, Saturday, 8 Jun 2002
The problem is that W3C XSD is "self-balkanizing" -- it's clear from this thread that the spec is so complex and obscure that in practice only its most basic features (roughly those it shares with DTDs an RELAX NG plus the basic datatypes) can truly be counted on to be interoperable across implementations and authoring tools, or understandable by any but the most specialized experts.
--Mike Champion on the xml-dev mailing list, Wed, 05 Jun 2002
The distaste for DTDs seems to be a politically correct kneejerk reaction. Quite apart from real and imagined flaws in their information content, I sense a prejudice that processing DTDs is inherently "difficult" (and thus something it might be useful to, um, "optimize away".) Can anyone offer a substantive reference explaining in detail the problems in processing DTDs, or is this yet another "truth" never to be examined? [Disclaimer: you may find considerable sympathy if you bash parameter entities, but only for the right reasons.]
--Arjun Ray on the xml-dev mailing list, Saturday, 18 May 2002
Writing for the Web without linking is like eating without digesting. It's literary bulemia.
--Doc Searls
Read the rest in The Doc Searls Weblog : Saturday, February 9,...
Internet is for everyone - but it won't be if parents and teachers cannot voluntarily create protected spaces for our young people for whom the full range of Internet content still may be inappropriate. Let us dedicate ourselves to the development of technologies and practices that offer this protective flexibility to those who accept responsibility for providing it.
Internet is for everyone - but it won't be if we are not responsible in its use and mindful of the rights of others who share its wealth. Let us dedicate ourselves to the responsible use of this new medium and to the proposition that with the freedoms the Internet enables comes a commensurate responsibility to use these powerful enablers with care and consideration. For those who choose to abuse these privileges, let us dedicate ourselves to developing the necessary tools to combat the abuse and punish the abuser.
--Vinton Cerf
Read the rest in fRFC 3271: The Internet is for Everyone
The ultimate goal has to be to find a middle way that addresses both the rights of copyright holders to protection of their works, and the rights of society to ensure those protections are limited and don't do harm to the general good. Copyright was invented for government censorship and military purposes. It became something for the good of society, and the USA acquired it in that form. Its important it remains for the good of society.
--Alan Cox
Read the rest in Slashdot | Alan Cox talks about laws... and Linux
SOAP rhetoric today seems to me as a big shell game. If you say: "SOAP doesn't work, it isn't interoperable and it doesn't do much", people will point you at all of the great SOAP RPC services (okay both of them) and say: "see, it is interoperable. It does everything that other RPC protocols do."
If you say: "SOAP sucks because it is RPC and RPC doesn't scale", people say: "no, it isn't RPC. If you think SOAP is RPC then you don't understand it."
So you can either have interoperability/actual usefulness or you can have vague promises of scalability in a wonderful message-oriented future -- with no demonstration of interoperability or actual usefulness. The most craven examples include people who say SOAP will replace HTTP because HTTP is synchronous and one-way, whereas SOAP isn't "limited to that". No, it isn't. But you also can't do anything else *interoperably*.
--Paul Prescod on the xml-dev mailing list, Sunday, 21 Apr 2002
I finally understand. REST is just a fancy marketing name for the stuff we've all being doing these last n years. And there was me trying to put off the day I had to learn about yet another new acronym.
--Michael Kay on the xml-dev mailing list, Monday, 20 May 2002
HTML processors being liberal in what they accept prevents reliable and widespread DOM and CSS ever taking off on the client side because who knows what the parse tree is; instead we get 'dynamic html" where the script tests what browser and OS it is running on as the first essential step and then deals with the few cases of browser and OS that it knows about. As web access devices diversify, this is more and more untenable. It simply does not scale.
This leads to the current tyranny of the legacy browsers which are defined entirely by reverse engineering (and the XML community contributes their support to this by "publishing to HTML" with XSLT) such that the entirety of the Document Formats and Interaction domain products are left out in the cold by the legacy browsers which currently define the Web. Newer stuff (SVG browsers, SMIl players, mobile devices that use an XML language that is not HTML) are the only areas where there is hope. The rest has fossilized into a non-architectural morass and is the single largest barrier to the e
volution and interoperability of the Web.
--Chris Lilley on the www-tag mailing list, Wed, 29 May 2002
reinventing HTTP would be a bad idea. Making a new protocol which is some way a whole lot better than HTTP is conceivable. I would expect such a protocol to be more general, not more specific. Inventing more specific protocols for given applications when what is happening is that data is being read or put to or posted to things in effect is clearly a bad idea.
--Tim Berners-Lee on the www-tag mailing list, Wed, 27 Feb 2002
Document people see the world in terms of XML encoded information flowing through systems, perhaps undergoing transformations and validations at various stages along the way. Data people see rigid XML structures flowing over the wire between well-defined end-points that encode all the really interesting stuff in "business logic" at the end- points.
The data people point out that, with a little effort, everything can be reduced to chucks of stuff that can be molded into a relational worldview. They are right. Document people point out that relational databases are horribly restrictive and do not naturally fit the way the world of knowledge seems to work. They are right too. The RDF and Topic Maps people point out that both view are right and wrong simultaneously. At a higher level of abstraction, its all-just relationships between atomic units of data, some of which are also relationships.
--Sean McGrath
Read the rest in ITworld.com - XML 2001: A Roller Coaster Ride for the Mind
You are strongly advised not to use CDATASection nodes. The advantage of having slightly prettier ways to print text that may have lots of embedded XML delimiters, such as "&" and "<", can be dwarfed by the cost of dealing with multiple kinds of text nodes in all your algorithms.
--David Brownell
Read the rest in GNU JAXP Library: Class DomCDATA
One of the current buzzwords is the Semantic Web and I am very excited by this vision: the Semantic Web is about making the web machine processable and in a way the Semantic Web is still trying to put SGML on the web. It's just that putting SGML on the web was not quite the same thing that we thought it was when we started out.
--Edd Dumbill
Read the rest in xmlhack: Revisiting SGML on the web
If you think of SVG as a toy technology to draw nice pictures, wake up! SVG is invading your cell phone and this "graphical XML" might wipe out "text XML" (such as XHTML and XSL-FO), just as graphical user interfaces have wiped out text-based user interfaces.
--Eric van der Vlist
Read the rest in xmlhack: Insatiable SVG or in French
As time goes on, I am having more and more difficulty believing in the notion of "general XML" - I have not seen and am less and less able to imagine a scenario in which one party sends another a message in "general XML".
--Tim Bray on the ietf-xml-mime mailing list, Thursday, 18 Apr 2002
It's (long past) time for people interested in the technology to push back against the people interested in the business of technology, even if that means biting the hand that feeds us. XML hype seems to be over - maybe it's time to get XML's technological house in order instead of chasing the big bucks.
--Simon St.Laurent on the xml-dev mailing list, 22 May 2002
Web services continue to be a substantial, viable threat to Windows. Because Web services components increasingly reside and run on servers that can be accessed with a variety of client devices, consumers will not be required to purchase Microsoft's desktop operating system in order to run the applications that they desire.
--Jonathan Schwartz, Sun Microsystems
Read the rest in Sun: Microsoft worried over Web services
There's a principle of genetics known as Fisher's Fundamental Theorem of Natural Selection (after Sir Ronald Fisher) which states that the better adapted an organism is to its current environment, the less of a change in its environment it can survive. Gerald Weinberg has observed that this applies to human inventions as much as to natural organisms, and it particularly applies to programs and the systems they're part of. Markup that's tightly coupled to the internal implementation details of its processors may use fewer CPU cycles (cheap, can throw more hardware at the problem) but is more likely to need rework (expensive, throwing more people at the problem seldom works) if the implementation changes. Tying in with another thread, I've seen people decide whether to represent something as an attribute or an element by measuring which a particular parser parses faster! That's a decision that could easily be rendered incorrect by a newer version of the parser, let alone moving to another parser.
--Eric Bohlman on the xml-dev mailing list, Friday, 17 May 2002
Namespaces don't provide much advantage as long as you deal mainly with your own vocabularies, i.e. you have full control, or nearly so. You'll find namespaces more attractive if you have to deal with vocabularies other people have set up, in particular if multiple independently developed vocabularies are involved.
--J. Pietschmann on the xml-dev mailing list, Sunday, 19 May 2002
Put no human-readable text in attributes, only tokens.
--Norman Walsh on the xml-dev mailing list, Friday, 17 May 2002
The frustrations with SAX are recapitulations of the same frustrations with the output of (n)sgmls - no surprise, since SAX is modeled on that implementation of ESIS, and even more closely on David Megginson's SGMLS.pm package. (Which is to say, SAX was not in any way an advance in the state of the art.)
--Arjun Ray on the xml-dev mailing list, Saturday, 18 May 2002
there is no formal model of data other than the relational one when it comes to storage of data. Hierarchical databases are a mess (try explaining IMS logical update rules to anyone), CODASYL (network) databases are ad hoc and object databases cannot even agree on a structure let alone a set of operators. XML cannot even get storage operators into its data manipulation model.
--John F Schlesinger on the xml-dev mailing list, Tuesday, 30 Apr 2002 19
XML never did a good job of being accessible to the DPH so of course that guy never materialized. Whenever I've tried to manipulate XML lexically I've run into huge problems with e.g. CDATA sections, entities etc.
--Paul Prescod on the xml-dev mailing list, Saturday, 26 Jan 2002
content-providers providing metadata about their own content is not what the semantic web is about. That would be like a WWW where you could only hyperlink to your own pages. The idea of the semantic web is that anybody can provide metadata about anyone else's stuff without getting permission, or needing the other resource to be on-line.
--Joshua Allen on the xml-dev mailing list, Sunday, 28 Apr 2002
XML is being used by the "man on the street" developer not just the MIT graduates who cut their teeth on Scheme and Haskell. So designing XML technologies as if they are expected to only be used by talented programmers with impressive educational pedigrees is probably not the wisest policy.
--Dare Obasanjo on the xml-dev mailing list, Monday, 25 Mar 2002
the SOAP HTTP binding should not be issued by the W3C as a Recommendation. Using HTTP for the sole purpose of tunneling other protocols through firewalls must be explicitly forbidden by standards bodies, even if Joe Hacker may do it on a regular basis. Liability for that kind of service rests with the software developers. If anyone doesn't like that, then they can bloody well use a raw TCP port 80 tunnel instead of HTTP -- they gain nothing from HTTP's overhead if they do not obey its constraints.
--Roy T. Fielding on the xml-dev mailing list, Friday, 26 Apr 2002
Many of the mistakes I encounter come of trying to make of XML what it is not. XML can express many styles of data laden trees, but that is where it stops. The two ways guaranteed to get howls are to design an XML type that exactly mimics the implementation, then claim that is a generalized solution (usually, a claim that it should be a standard) or to create a generalized solution (usually a standard) and hand that to an implementer who knows it doesn't apply to his or her problem (the case for LegalXML is weak outside the US, and I suspect this is true of many e-gov and e-business specifications for XML document types and schemas).
XML Doesn't Care. That's why it scales. XML implementors have to care; that is why they freak out a lot.
--Claude L Bullard, on the xml-dev mailing list, Monday, 29 Apr 2002
finding the right simplifications is not always easy, especially in a large committee. People (me included) are always less likely to fight against the addition of a feature they consider unnecessary than against the removal of one they really like, so it's always hard to make the language smaller.
--Michael Kay on the xml-dev mailing list, Monday, 6 May 2002
XML has largely succeeded as defining an exchange syntax. No longer does the world _need_ to argue over whether to use angle brackets or parens to delimit tokens. Whoopee!!
--Jonathan Borden on the xml-dev mailing list, Monday, 6 May 2002
There are more things in Heaven and Earth than are dreamt of in RFC 2396.
--Miles Sabin on the xml-dev mailing list, Friday, 26 Apr 2002
Personally, I recommend that customers never include a DOCTYPE in a production-grade XML document (there are probably good reasons for an exception somewhere, but I haven't found them yet). DOCTYPE is the biggest security hole in XML, and it causes all kinds of problems that non specialists (i.e. the poor people who have to maintain the system) are not equipped to deal with, and that even specialists sometimes have trouble with; it gives very few benefits in exchange. DOCTYPE is useful on the authoring side for editing software, validation, etc., but it should be stripped off when the document goes out the doors.
--David Megginson on the sax-users mailing list, Wed, 1 May 2002
one of the things that always mystifies me is how anybody in corporate America will run Outlook. I mean to say that, "they don't have a security story," is being very charitable. I mean, it's a petri dish. Opening a piece of e-mail in Outlook is really asking for it.
--James Gosling
Read the rest in Q&A Part III: Java creator Gosling on Java tools, his move to Mac
There is nothing special about XML except the extent to which everyone's converging on it. All the tools that are consequently available to produce, parse and process XML (independent of application) make it a pretty attractive data and data exchange format.
--David Gallardo on the "Computer Book Publishing" mailing list, Wed, 1 May 2002
Flash will dominate for a little while longer - but I would also be willing to bet that by 2004, the Flash player will read SVG, and by 2005 Macromedia will have made it (with namespace extensions, no doubt) the primary format in the Flash player, at which point the whole discussion is moot.
--Kurt Cagle on the "Computer Book Publishing" mailing list, Wed, 24 Apr 2002
Rightly or wrongly, many people see RDF as Prolog in XML syntax, and the vision as being disturbingly similar to the Fifth Generation project/vision/hype of the early 1980's in which logic programming was going to put the hackers out of business and lead Japan (the center of interest and research in this field) to world economic domination. Other techniques/paradigms that came out of one or another branch of the AI community over the last 25 years have had similar patterns of overwhelming hype / underwhelming success.
--Mike Champion on the xml-dev mailing list, Wed, 24 Apr 2002
To say that the race is over is like saying that the web today is all the web will ever be. The finish line is tearing off into the distance. Although the point is made that Flash & SVG aren't in exactly the same space, the argument that Flash is way ahead seems to depend on this being the case - a huge user base today isn't the end of the story. The fact is, SVG is far more suited to the web environment than Flash because of its XML base. For *tomorrows* applications, SVG has a head start. Any XML-capable application can deal with SVG, and there are a lot of these applications around - a couple of significant examples are XML databases, content management systems, and of course Microsoft's .NET stuff is all built around XML, so is capable of delivering SVG and even generating it on the fly without modification. The tools at the user end (browsers/plugins and design tools) still have a way to go, but do I think that SVG is approaching critical mass - to mix a metaphor, the ground is extremely fertile for SVG, and seeds are blowing around right now.
--Danny Ayers on the "Computer Book Publishing" mailing list, Monday, 29 Apr 2002
Web services absolutely will create new security weaknesses. These services are not being designed by bankers. Many services we see, especially those built by smaller firms, are not actually built using real financial security people. As a result, they don't really know how to even comply with federal regulation sometimes regarding the security of their system.
--James Molini, Brink's Internet Security
Read the rest in Dark side of cyberlife - Tech News - CNET.com
Internet is for everyone - but it won't be until in every home, in every business, in every school, in every library, in every hospital in every town and in every country on the Globe, the Internet can be accessed without limitation, at any time and in every language.
Internet is for everyone - but it won't be if it is too complex to be used easily by everyone. Let us dedicate ourselves to the task of simplifying the Internet's interfaces and to educating all that are interested in its use.
Internet is for everyone - but it won't be if legislation around the world creates a thicket of incompatible laws that hinder the growth of electronic commerce, stymie the protection of intellectual property, and stifle freedom of expression and the development of market economies. Let us dedicate ourselves to the creation of a global legal framework in which laws work across national boundaries to reinforce the upward spiral of value that the Internet is capable of creating.
--Vinton Cerf
Read the rest in fRFC 3271: The Internet is for Everyone
There is no one thing called "the Web", there are many different loosely bound technologies being used in a wide variety of ways. The web services architecture, the semantic web, the HTML + HTTP web page architecture, and the data integration scenarios envisioned by some people in the XML Query community are all examples of web architectures. There are others.
So asking "What is the Web" is a bit like asking "What is Data"? I think it is a mistake to come up with one prescriptive answer to the question.
--Jonathan Robie on the xml-dev mailing list, Friday, 26 Apr 2002
XML is a useful technology for programmers and their ilk, but end users need to know about XML just as much as they need to know about SQL, Java, OOP, and all the other babble that goes on behind the scenes to make the world's computer technology function as well (or as poorly) as it does.
--Ray Lischner on the "Computer Book Publishing" mailing list, Monday, 22 Apr 2002
XML suffers from the same problem that SGML did originally (or PDF and SVG for that matter) - wonderful technology whose direct applicability is beyond the hands-on interest or vision of most users - even those who could profit from using it. For one thing, the idea of determining schema for an enterprise and then painstakingly applying it to content generated within that enterprise is a non-starter - unless the payoff is significant. If you even suggest the benefits of implementation, you might be called upon to do the work yourself - and it just doesn't seem to be much "fun."
By contrast, the powerful PDF (aka, Adobe Acrobat) technology is extremely fun. It may be that the more that PDFs are used to solve publishing problems (i.e., reflow for use on Palm OS), the more tagged content will come into vogue for enterprising content publishers.
--C. Scott Miller on the "Computer Book Publishing" mailing list, Monday, 22 Apr 2002
Namespaces and whitespace; anything that ends with space in XML is a pain in the butt.
--Jason Hunter
JDOM makes XML Easy, Software Development 2002 West, April 26, 2002
its positively *scary* the number of apps out there in the real world that have wired the processing to the prefix - not the fully qualified name.
--Sean McGrath on the xml-dev mailing list, Wed, 30 Jan 2002
Some Internet marketing managers just don't want hot leads to visit their website. I conclude this after hearing that website owners actually call search engine customer service departments complaining that users are daring to enter sites directly on pages they're most interested in. These callers would prefer search engines that link users only to the homepages and never to pages inside the site.
--Jakob Nielsen
Read the rest in Deep Linking is Good Linking
The fact of the matter is that most CGI scripts are not HTTP compliant. Most CGI scripts, in fact, provide interfaces to applications that suck. The "G" stands for Gateway. What people should realize is not that "CGI scripts should be banned", but rather that if the CGI script is written such that it behaves like a proper Web interface, then it won't suck. The point is to describe to developers the ways in which an interface can be better implemented on the Web. REST is not the easiest way to provide an interface on the Web. In fact, doing it right requires fairly sophisticated software. CGI makes life easy for programmers. REST-like operation makes life easy for users and content maintainers.
--Roy T. Fielding on the www-tag mailing list, Tuesday, 16 Apr 2002
If I have a URI to an angel, and another URI to a pin, how many URIs to that angel can I PUT on the HEAD of the pin?
--Mike Dierken on the www-tag mailing list, Thursday, 18 Apr 2002
I think that adding NEL is in fact a more correct usage of Unicode than what XML 1.0 specifies. I'm still against it because it has a lousy cost/benefit trade-off. XML 1.0 achieves a pretty good balance of making the benefits of Unicode available without incurring much in the way of cost for users of legacy text-processing systems. I think the linebreak aspects of Blueberry are a step back in that respect.
--Tim Bray on the xml-dev mailing list
There will be a little core of simplicity that will arise out of XML someday, just as XML arose out of SGML. May the circle be unbroken.
--Jeff Lowery on the xml-dev mailing list, Monday, 15 Apr 2002
XML is being used by the "man on the street" developer not just the MIT graduates who cut their teeth on Scheme and Haskell. So designing XML technologies as if they are expected to only be used by talented programmers with impressive educational pedigrees is probably not the wisest policy.
--Dare Obasanjo on the xml-dev mailing list, Monday, 25 Mar 2002
XML has never been about guaranteed interoperability. Rather, it means that if you pick a conservative character encoding, and conservative name characters, and conservative data characters, and only use reliable URIs for system identifiers and links etc, and send standalone documents, and normalize your document correctly before you send it, you can expect your data to go through.
--Rick Jelliffe on the xml-dev mailing list, Sunday, 24 Mar 2002
I really don't see any domain where XML Schema is preferable to RELAX NG, apart from tool support. And why has XML Schema a better tool support ? Because it is so. Because everybody let the market decide instead of making an decision in good faith. Because XML Schema was proposed by the W3C, which is sponsored by vendors. So vendors influenced vendors, and what we get is a vendor-friendly technology (expensive to implement (even in open-source), expensive to use, with nice formal specs to please nerds and make sure that common people can't get it).
--Nicolas Lehuen on the xml-dev mailing list, Wed, 27 Mar 2002
URIs are the single fundamental technology that enables the web to exist. we could lose http, html, perhaps even DNS and still have a working web. (less functional, but it would still work) but without URIs, without the ability to reference resources *outside* the boundaries of any particular information service, there would be no web.
--Keith Moore on the xml-dev mailing list, Wed, 10 Apr 2002
Without hyperlinking you don't have the Web. Without GET you don't have hyperlinking. Hyperlinking is a critical piece of any non-trivial web service because it is the Web's way of managing state. COM has Monikers. CORBA has IORs. The Web has URIs. SOAP does not have GET and it is not possible to address SOAP-fetchable information. Therefore SOAP is something other than the Web and actually quite a bit less powerful than the technologies it is supposed to replace.
--Paul Prescod on the www-tag mailing list, Wed, 27 Mar 2002
the job of defining monster "one size fits all" uber-DTDs is almost beyond the scope of human intelligence, even without political and bureaucratic hinderances. To touch on my favorite subject, the power of XML (IMHO) comes from its ability to deal with chaos gracefully rather than insisting on order.
--Mike Champion on the xml-dev mailing list, Friday, 05 Apr 2002
Doctor, Doctor, it hurts when I dereference a namespace URI!
--Mark Baker on the xml-dev mailing list, Friday, 5 Apr 2002
By conflating the tasks of validation and lightweight transformations (such as attribute and element defaulting), DTDs and XML Schema force a coupling between processing models in endpoints of a document exchange. Both must perform validation in a functionally equivalent manner to correctly interpret document content rather than simply relying upon the explicit infoset in the document. So what is this coupling really buying us in terms of functionality?
--Michael Brennan on the xml-dev mailing list, Thursday, 28 Mar 2002
Getting specs done is largely a matter of reducing your ambition to the point where someone actually has time to do the work...
--Richard Tobin on the xml-dev mailing list, Wed, 3 Apr 2002
Using URLs as example URIs in the namespaces spec was a bad idea. It led people to think about dereferencing namespace names which, if you think about it, is about as odd as dereferencing Java package names. Sure, you can come up with a mechanism to do it, but why would you want to?
--Ronald Bourret on the xml-dev mailing list, Thursday, 04 Apr 2002
A new XML version must reflect the last 4 years of development. If time is the obstacle for doing the substantial changes to XML as Tim Bray and others have proposed, I think it's better to stop. Do it right, or don't touch it.
--Gustaf Liljegren on the xml-dev mailing list, Thursday, 04 Apr 2002
My first impression is that the current OpenOffice is frustratingly close to being useable as a substitute for Word for writing books for publishers who insist on Word-format files, but isn't quite there yet. I'd love to be proven wrong, though.
--Rod Smith on the "Computer Book Publishing" mailing list
A document on the Web is a stream of bits identified with a specific MIME type. The MIME type indicates to the processor how it may interpret the stream of bits to decompose it into a sequence of characters, for example, or a specific bitmap image.
--Norman Walsh and Paul Cotton
Read the rest in What Does a Document Mean?
The "savaging" of ISO and SGML was what resulted in XML in the first place, and though stakeholders in SGML might not like it, the reality is that this represents huge progress. The W3C scored a huge PR coup first with HTML and then with XML. It is only natural that people would expect it to be the source of the "official" XML schema language as well. And it is undeniably true that the XML Schema WG brought together an impressive array of talented and knowledgeable individuals. It is a direct consequence of the huge influence of the W3C that XSD attracted so much attention, and as a direct consequence of that XSD has the flaws that it does (and it is probably fair to characterize this as almost universally linked to neglect of the "80/20 rule").
--Matthew Gertner on the xml-dev mailing list, Tuesday, 26 Mar 2002
The great innovation of SGML was requiring documents to define their own type. The great innovation of XML was to remove this requirement. Relying on the XSD PSVI would be a step backward. Using RELAX NG is a step forward.
--Joe English on the xml-dev mailing list, Tuesday, 26 Mar 2002
people are won over to XSLT once they have a chance to get some perspective, and this usually doesn't take long at all. I have had much occasion working with developers who curse and splutter all the time at all the little tripping points of XSLT that Mike Kay points out. But at least twice, I remember a developer saying, after a few days of this, something to the effect of "wow, XSLT is certainly a different way of thinking, but I must say that I accomplished my XML processing task using XSLT in a fraction of the time it took for me to do the same with DOM and Java".
--Uche Ogbuji on the xml-dev mailing list, Monday, 25 Mar 2002
I've heard it said that WSDL 1.1 is both half-cooked and unnecessarily bloated. If the big guys who are beating these drums want to ship this stuff as specified, they can do this--it's a free economy--but if they want the W3C imprimatur, there has to be some process and thought and time.
--Tim Bray
Read the rest in Critics clamor for Web services standards
To wrest control away from the user by intrusively altering preferences without asking permission leaves the user with an unpleasant experience.
--Otto Avila on the WWWAC mailing list
I don't find XML Schema graceful or beautiful, but I do think it is useful, and it is widely implemented in commercial products. I do find RELAX-NG both graceful and beautiful, but commercial support for it is very limited.
--Jonathan Robie on the xml-dev mailing list, Thursday, 21 Mar 2002
Most DBMS systems do not perform any checking of encoding. So you can store almost anything in, say, a DBMS expecting ISO 8859-1. With a world full of data incorrectly labelled, there is no chance of good interoperability without some basic checking. And those basic checks are what XML's data character and naming rules provide.
Without them, sure XML would be "simpler" and we could attempt to transmit arbitrary strings around. But then encoding detection or repair would be the problem of the recipient and not the sender: a responsible recipient can have no faith that their non-ASCII data has not been corrupted.
And that lies at the heart of the matter: if we allow control characters and silly name characters, we won't actually increase the number of characters that can be reliable sent: we will just make non-ASCII characters suspect and unreliable.
--Rick Jelliffe on the xml-dev mailing list
the semantic web is on the same level as flying cars and elevator rides to the moon; a nice but impractical and infeasible dream.
--Dare Obasanjo on the xml-dev mailing list, Tuesday, 19 Mar 2002
The whole dot-com thing was an effort to use 19th and 20th century concepts of economy in an environment where they didn't exist, and the Internet essentially shrugged them off. This was an assault by an alien force that was repelled by the natural forces of the Internet.
--John Perry Barlow
Read the rest in Tech News - CNET.com
people may need to come to the realization that Unicode may have exceeded the point where we can expect any member company, or any other company for that matter, to implement *all* of Unicode.
Think what that means. The Unicode Standard is the *universal* character encoding. It is intentionally scoped to deal with all characters for all scripts, living and extinct. Getting software to cope with *all* writing systems, including long dead ones, is a pretty tall order. And the encoding is gigantic and getter larger.
--Kenneth Whistler on the unicode mailing list, Wed, 13 Mar 2002
I use DTDs for their most excellent powerful, intuitive, consise, extended regular expression notation. I eschew all the other stuff heaped in there from the SGML days where possible. It is truly exasperating to see *ML.org sites being created at a rate of knots and their drivers getting all "deeply committed" to W3C XML Schema without thinking through the implications. Especially for document-oriented XML applications.
--Sean McGrath on the xml-dev mailing list
people will adopt a technology if they believe that everyone else is going to do so. The early adoption (which happened for all the technologies you listed) comes from individual users for whom the benefit exceeds the cost. The bulk adoption comes from people who get a benefit (either a real benefit, or just a sense of security) simply from doing the same as others are doing, or more importantly, from doing what they *think* others will be doing: the "self-fulfilling prophecy".
Synergy benefits are critical: you adopt Unix (or Windows) not because you think it is a good operating system, but because you believe that everyone else will use it and therefore there will be lots of applications and low prices. As a technology designed for interworking, XML obviously has very high synergy potential so long as everyone believes in it.
--Michael Kay on the xml-dev mailing list, Saturday, 16 Mar 2002
WML is not a complicated presentation language, and its XML root make it easy to write well formed and valid WML content. Even if real WAP phone have different behaviours and bugs (by having written an adaptation layer that handles 60+ WAP phones, their specific screen sizes, behaviours and bugs, I can tell it), the situation is much better than if we had 60+ phone models based on a loose HTML subset.
--Nicolas Lehuen xml-dev mailing list, Monday, 11 Mar 2002
advertising doesn't work on the Web because it's contrary to the fundamental nature of the user experience: goal-driven navigation. (The exceptions are search-engine ads and classified ads; these support users' goals instead of thwarting them.)
Some advertising executives are still in denial and think that ever more intrusive and annoying ads will be the Web's salvation. Wrong. If a website degrades the user experience too much, people will simply stay away. There are already several sites I am reluctant to visit because they pollute my screen with pop-ups.
--Jakob Nielsen
Read the rest in User Payments: Predictions for 2001 Revisited...
The notion that representation is as important as underlying structure, which XML's syntactic rules make fairly explicit, is deeply alien to the Platonic view of information that many programmers seem to share. The notion that lexical structure might be as important as the underlying information is one that even this community frequently has difficulty with, but it seems to be at the foundation of XML 1.0.
--Simon St.Laurent on the xml-dev mailing list
I look at XForms and remember the firestorm of critique over the US Navy MID design from the HTML community that was pretty darned clueless about why such designs were sponsored and I think, it's just timing and requirements. XForms takes the same tack, adds web spaces, and voila, MID lives. Most of what I see today is a recycling of ideas either copied or rediscovered and implemented over the web substrate. In that sense, the web has succeeded in providing an infrastructure and the only question is will the middle hold once the retooling of the lower layers gets into high gear.
--Claude L (Len) Bullard on the xml-dev mailing list, Tuesday, 22 Jan 2002
If folks go around making new protocols for each new application, then either the web will fragment, or we will have huge client bloat as each device (cellphone, wristwatch, camera, etc) has to have the latest set of client protocol modules. Clients need to get smaller, not larger, at this time.
--Tim Berners-Lee on the www-tag mailing list, Wed, 27 Feb 2002
The TP in htTP stands for transport protocol. An address starting with 'http://' is like a stamped postcard with an address written on it. Of course, you're not obligated to mail it, though not doing so would be an exceptional case.
--Micah Dubinko on the xml-dev mailing list, Tuesday, 5 Mar 2002
As a long time Emacs user, I now freely admit that I don't think text editors are a good way to edit XML, XSL-T, etc. Really, the syntaxes we have for C, C++, Java, Python, etc. are the syntaxes you get when people use text editors, and approach life as though text editors are the be-all and end-all of editing. There isn't a problem with XSL-T having an XML syntax, unless you insist on using a text editor to edit it. I mean, you can use one if you want, but of course you will end up feeling like you need to complain to somebody.
--Tony Coates on the xml-dev mailing list, Monday, 04 Mar 2002
UDDI is useless regardless of its technical architecture, because its scope is way too broad. The promises made for it are unattainable.
--Paul Prescod on the xml-dev mailing list, Friday, 01 Mar 2002
XSLT is good when you are going from the data layer pretty directly to the presentation layer. If you need to do a bunch of "procedural code" things between the data and presentation layer, you probably want to use a procedural language.
--Joshua Allen on the xsl-list mailing list, Wed, 30 Jan 2002
Ruple is essentially a melding of the Web, Linda, and XML.... and as near as I can tell is consistent with REST principles, using essentially PUT, GET, and TAKE (=GET+DELETE) as its primitive operations. Are we seeing the outlines of a new meta- model for large scale software architecture that challenges a lot of the received wisdom of the OO paradigm? That is, perhaps "encapsulation" of data is not such a good thing after all ... or at least it's not scaling well to the Web. Perhaps it makes more sense to expose the data via generic operations rather than exchange objects that encapsulate data behind customized operations.
--Mike Champion on the xml-dev mailing list, Friday, 01 Mar 2002 00
Vendors want you to think that SOAP solves all your problems. It doesn't. The layers above SOAP solve your problems and you have to *buy* them. Like Dowty Trailblazer modems in the Eighties, uber-SOAP stacks will work best talking to another copy of themselves. There is a viral business model there.
--Sean McGrath on the xml-dev mailing list, Wed, 27 Feb 2002
If we rely on HTTP we will melt the Internet. We at least have to raise the level of abstraction, so that we have an industry-wide way to do long-running requests -- I need a way to send a request to a server and not get the result for five days.
--Don Box
Read the rest in Microsoft: Now HTTP needs replacing
The current practice is we set the goal of producing royalty free standards but it doesn't really have a mechanism for enforcing that. What we're proposing in this draft is to add a legally binding commitment on the part of anyone who participates in a standard that any patents they have will be available royalty free.
--Daniel J. Weitzner, W3C Patent Policy Working Group chairperson
Read the rest in W3C retreats from royalty policy
One wonders what kind of racket
would think to use so many brackets?
They say it's well-formed,
but it looks more de-formed;
My eyeballs go cross when I track it.
--Jeff Lowery on the Xml-Dev mailing list
Spammers and geeks are managing to do to China's people what the government has attempted but been unable to do. We are slowly being cut off from participating in the most democratic system ever developed -� e-mail.
--Mike Markham
Read the rest in Not All Asian E-Mail Is Spam
We've reached a point where the media are so owned by the large corporations and they live in this tight loop where practically all they can convey is what is already believed. I believe that mass media exists to confirm the hallucinations of the masses. If you want to get a story through that doesn't sync up with the dominant belief system, it's just not going to happen. So who the hell knows what else is going on out there?
--John Perry Barlow
Read the rest in Tech News - CNET.com
There also seems to be a pursuit of some holy grail of "reliably pointing to resources", but unfortunately you can't and never will be able to. Using PUBLIC ids instead of URIs/URLs/URCompletelyConfusedByAllTheAvailableAcronyms doesn't solve the problem in the slightest, just moves it somewhere else. Companies will go out of business or change the organization of their publicly available resources. Networks will go down and computers will do things for "no apparent reason"(TM). Hackers will spoof web sites and send viruses instead of whatever it was you really wanted.
--John Anderson on the xml-dev mailing list, Thursday, 21 Feb 2002
The hype merchants are out of control on this on. I think that "Web services" in general is at least as experimental and unproven as the Semantic Web.
--Tim Bray
Read the rest in Critics clamor for Web services standards
E-mail as a communication medium is under attack. If an organization discovers that blocking an entire country will stop a huge amount of spam, it does make a lot of financial sense for them to do so. But this retreat into e-mail enclaves also destroys one of the best things about e-mail -- the ability to communicate freely with someone on the other side of the world, even if it's just a "Hi from China, I really liked your Web page."
--Steve Atkins
Read the rest in Not All Asian E-Mail Is Spam
A namespace is punctuation. If someone chooses to use a namespace as an alias or synonym of a vocabulary or document model, then that is poor practice and is a good example of why there is so much confusion about what a namespace correlates to.
--Patrick Stickler on the WWW TAG mailing list, Monday, 18 Feb 2002
The W3C was favored by the movers and shakers as a place to hammer out modus vivendi in the days when HTML and DOM interoperability was the critical issue. For various reasons, the W3C is no longer a useful forum for "lets just make this WORK" discussions. As the debates over W3C XML Schema, the Semantic Web, and XQuery here (and the SOAP/REST discussion on xml-dist-app) have made clear, the W3C is focused these days on trying to Do the Right Thing and build a theoretically grounded foundation for the future more than a pragmatic accomodation for the present.
--Mike Champion on the xml-dev mailing list, Thursday, 07 Feb 2002 14
The ever-rising price of MS office is increasingly pushing companies to look at Star Office both on Windows and on Linux. In many ways the effective forty per cent price hikes in Microsoft pricing have been the biggest driver of Linux on the desktop.
--Alan Cox
Read the rest in The ITW Interview
However much everyone argues, URIs remain the same unchanging black hole. I see a lot of people heading off to their own corner to build systems which use URIs (or ignore them in favor of QNames) however they see fit - and less and less chance of making the systems share a common understanding.
--Simon St.Laurent on the XML DEV mailing list, 15 Feb 2002
If the business people who rule the entertainment industry had been as powerful 25 years ago as they are today, you'd be breaking the law if you set your videocassette recorder to tape your favorite Olympic event for later viewing. The VCR, assuming the entertainment industry would have allowed a manufacturer to sell it, would not have a fast-forward button because it would let you skip through the commercials without viewing them.
As for tape recorders, you would not have been able to make a copy of the music you just bought so you could play it in your car.
--Dan Gillmor
Read the rest in Mercury News | 02/12/2002 | Entertainment industry's copyright fight puts consumers in cross hairs
XML succeeded, and in ways that weren't expected - at least not by many. Originally it was conceived as a document-oriented technology for robust quality publishing of documents over networks. the original workplan had three pillars - XML syntax, XML link, and XML stylesheets. Schemas were not high on the agenda and XML was not seen as an infrastructure for middleware or glueware. It was expected that at some stage it would be necessary to manage data but there was little activity in this area in 1997. When developing Chemical Markup Language (which must be one of the first published XML applications), I found the lack of datatypes very frustrating!
Well, XML is now a basic infrastructure of much modern information. I doubt that anyone now designs a protocol, or operating system without including XML. Although this list sometimes complains that XML isn't as clean as we would like, it works, and it works pretty well.
--Peter Murray-Rust on the xml-dev mailing list, Thursday, 07 Feb 2002
What bothers me is when the reporters covering these things oversimplify and make it sound like there are two armies facing off. In xml-dev, people have opinions all over the map; there is no way that the community can be categorized so simplistically into these two supposed camps. I would think of it as just silly reporting except that I have seen too many times where people read about some "war" and start thinking, "hmm, what side am I on?", and feed the polarization that never really existed in the first place.
--Joshua Allen on the xml-dev mailing list, Tuesday, 12 Feb 2002
A misconception that many technology folks have (and I am specifically not addressing this to you in person, or to anyone in particular) is that the technology exists to be pure, or elegant, and that code exists to be efficient. The technology exists for what it _does_, for the benefits that it delivers to those who use it. The benefits of cooperation outweigh elegance of syntax. This is particularly true of XML. S-expressions which have existed at least since the 1960s really are more elegant, compact etc. than XML, but so what?
--Jonathan Borden on the xml-dev mailing list, Friday, 1 Feb 2002
In my 16 years of standards work, I've learned that if you want a standard to work, you have to think like an engineer. But if you want it to be adopted, you have to think like a politician. The two mindsets are sometimes incompatible. Where they were incompatible, I've generally chosen to make the standard really work, in preference to early, easy adoption. For me, it's a professional thing.
--Steven R. Newcomb on the xml-dev mailing list, 25 Jan 2002
web services specs are the hostage of a heated vendor war to be the first to really rake in bucks selling web service tools and servers. The vendors are thrashing about in a frenzy looking for that quick rubber stamp on a "standard compliant" label they can stick to their products.
--Michael Brennan on the xml-dev mailing list, Thursday, 7 Feb 2002
XPath and XSLT operate using a data model that is at a level just slightly higher than the character-data-divided-into-elements-and-attributes as imposed by the markup and reported by the XML parser. This DOM-like model uses node trees to represent the source document, the transformation result prior to its automatic serialization by the XSLT processor, and even the stylesheet itself. If you fully appreciate this model and the processing model that XSLT uses, then 99% of the time, any arguments for using disable-output-escaping are exercises in kludgery (pardon my invention of new words here) that are aimed at working around (mis)perceived shortcomings in the result tree serialization process rather than understanding how to manage the content and the transformation correctly, from an XSLT processing standpoint, in the first place.
--Mike Brown on the xsl-list mailing list, Tuesday, 5 Feb 2002
XML is the worst possible solution, except for all the other solutions.
--Lincoln Stein
Read the rest in O'Reilly Network: Bioinformatics Conference
If the standard wants me to confuse the user, I would rather dump the standard than comply.
--Gaspar Sinai on the Unicode mailing list, Tuesday, 5 Feb 2002
There's nothing worse than upgrading to a supposed "bug fix" release that makes your stuff stop working.
--Joel Spolsky
Read the rest in The CityDesk Forum - SP1 Smoke Test: Send Us Your Files
It is not surprising that architectural forms bend people's minds -- they completely invert the standard model like quantum physics and relativity.
--Paul Prescod on the xml-dev mailing list, Thursday, 31 Jan 2002
I'd be *really* upset if someone designed the flight control system of commerical airliners like we did the WWW.
--Gavin Thomas Nicol on the xml-dev, 22 Jan 2002
In XML you can have element type names in Yi, allowing villagers in southern China to have XML vocabularies in their native language, but current W3C practice requires certain of their element types to have English names (and awkward ones at that) in order to be interoperable. How much sense does that make?
--Lars Marius Garshol on the xml-dev mailing list, 31 Jan 2002
We have nothing but anecdotal evidence for this; but experience does indicate that when used for the tasks for which it was designed, XSLT really is pretty darned easy. The only thing hard is writing gnarly XPaths; but some people think even that's fun.
XSLT is especially easy if the source data is designed well (thus obviating most of the need for gnarly XPaths). Which suggests that much of the reason XSLT is "hard" is that people just don't know how to design good XML.
--Wendell Piez on the xsl-list mailing list, Friday, 25 Jan 2002q
Binary file formats are less likely to be mucked up than text ones because nasty humans aren't getting silly ideas in their head about hand-editing them! Sorry, couldn't resist.
--Al Snell on the xml-dev mailing list, Tuesday, 29 Jan 2002
Sure I want to be the biggest telecom company in the world, but it's just a commodity. I want to be able to form opinion. By controlling the pipe, you can eventually get control of the content. If anyone can make it work, we can.
--Howard S. Jonas, IDT chairman
Read the rest in For IDT, the Big Flameouts Light Its Fire
The DOM (like XML) is not a triumph of elegance; it's a triumph of "if we do not hang together, we shall hang separately." At least the Browser Wars were not followed by API Wars. Better a common API that we all love to hate than a bazillion contending APIs that carve the Web up into contending enclaves of True Believers.
--Mike Champion on the xml-dev mailing list, Thursday, 27 Sep 2001
XSLT may be sexy, but DSSSL is beautiful
--Ian Castle on the docbook-apps mailing list, Friday, 25 Jan 2002
the point is that "The Web" is an emergent phenomenon of all those varyingly hooked-up pieces, just as Len Bullard is an emergent phenomenon of a bunch of ever-changing cells, and that treating it as if it were a physical object would be committing the fallacy of reification. A person, a river, or a Web are in many ways best thought of as processes rather than things.
--Eric Bohlman on the xml-dev, Friday, 25 Jan 2002
It makes more sense to design for the mainstream and have the outliers adapt for special cases than to do the opposite.
--Paul Prescod on the xml-dev mailing list, Wed, 23 Jan 2002
Someday we'll wake up and realize that, from an information management-and-interchange perspective, it's very, very useful for an element to declare that it's an instance of multiple element types, and to be able to invoke full syntactic validation of such instances against all their classes, in syntactic space, including both context and content. Anything less is suboptimal as a basis for flexible, mix-and-match information interchange via XML, among people who want to cooperate with each other, but who have endlessly specialized local requirements. Architectural forms, anyone?
--Steven R. Newcomb on the xml-dev mailing list, 23 Jan 2002
RDDL is like handing the end user of a TV set a bunch of different manuals describing switches, CRTs, integrated circuits, and electric cords. While a user can figure out how to turn on the TV set and adjust the volume from these manuals, it is unlikely they will do so.
In documentation terms, RDDL is a reference manual and only low-level people (e.g. TV repairmen) want reference manuals. Everybody else wants a user's guide.
--Ronald Bourret on the xml-dev mailing list
I cringe everytime I see "worse is better" referenced, especially when it's applied to the Web. The Web is better because it was designed to be better.
"worse is better" is usually used by people who don't see the larger context in which a system is designed, and don't understand all the tradeoffs that were made. So they pick on one or two pieces and say "see, that's clearly worse because it could have been done so much better this way", without recognizing that doing it that way would have forced some unacceptable tradeoff to be made elsewhere.
--Mark Baker on the xml-dev mailing list
Installing server software is just much harder than installing Windows software. There are always multiple complicated steps that involve permissions, accounts, database servers, dependencies (do you have the absolute latest version of perl?), superuser, and web servers. If you're using free software, nobody wants to volunteer to make a decent setup program (or even documentation, half the time), so you're generally on your own there. And when you're using commercial software, the vendor would usually like to sell you a three-week integration consulting project so they can make another $50,000 copying some files and editing some configuration files.
--Joel Spolsky
Read the rest in Joel on Software - Working on CityDesk, Part Two
characters != bytes != encoding. If you start allowing control characters (which are somewhat debatable *as* characters in the first place), it becomes very easy to abuse the power and to have application-specific uses of embedded encodings.
--Gavin Thomas Nicol on the xml-dev mailing list
It's starting to look like the multiple uses of XML demand multiple schema languages, not one XML Schema language which binds us all.
--Adam Turoff on the xml-dev mailing list
XML is easy. It is the problems people are trying to address with XML that are hard.
--Jonathan Borden on the xml-dev mailing list
No standards committee is going to be a leader in innovation. The innovation will come from other corners -- from those in the trenches who need particular tools, so they invent them. And no such innovation is going to happen from someone who insists they will adopt no solution that has not been sanctioned in advance by the W3C.
--Michael Brennan on the xml-dev mailing list
XSLT has perhaps the most phenomenal adoption rate of all programming languages of all time. It's always hard to measure this sort of thing from users, so I measure it by actively-developed implementations. Neither C, C++, Java, or even my favorite Python have had anything like the growth of vibrant culture in XSLT development. People like XSLT because it gets its task done very well, and so vendors are anxious to provide XSLT support to users.
--Uche Ogbuji on the xml-dev mailing list
In the Object oriented world data is a second class citizen. Objects control access to and provide operations on data. Traditional functional modeling techniques on the other hand are often much more data centric. This data focus however is often cited as a fundamental weakness in these approaches, the separation of data from the functions that manipulate that data is often cited as the principle cause of complexity in non OO development. Objects, through exclusive ownership of their data, reduce complexity by leveraging abstraction and encapsulation to capture a more natural and maintainable model of their problem space. Until recently it looked like data would stay in the shadows, objects seemed to have the advantage.
XML however starts to reverse the clock, it represents a change in course back to a more data centric world, one in which data has a life of it's own. Data has effectively broken free of its object boundaries. This however does not mean a return to data modeling techniques of the past but it does present new challenges to those accustomed to OO development. The natural tendency for some OO practitioners will be to place the XML inside objects, hide it somehow and try and get things back to the familiar world of objects where they have experience, tools, methodologies and comfort. This might make sense if XML was simply a better way to represent data. XML however is much more than just data, it is an extensive and expanding set of standards and technologies. XML and objects will have to co-exist as peer technologies, objects must start to share the spotlight.
--Stephen Kirkham
Read the rest in XML - A Disruptive Influence on Programming Languages
Why rush? Who is rushing and why? As a user, I want something small, simple to understand, that works. I don't mind if it does not unify the Universe into one cohesive theory. I'd like that but I can wait for it. If a bunch of smart people advise that we should re-visit some core data model issues before layering on more standards, so be it. In fact, I'd be delighted because it would show concern for the deep longevity we are all seeking in data standards.
"Standards" should not be rushed. They should take as long as they take. Especially when they are as complex, far-reaching and require innovation as XQuery does.
--Sean McGrath on the xml-dev mailing list
An XSLT transformation
May often be cause for frustration
When escaping disabled
Is mistakenly labeled
Solution instead of temptation.
--Jeni Tennison on the xml-dev mailing list
Since the split of XSL into XSLT and XSLFO and the decision that the FO and the CSS display models will converge, it doesn't make much difference whether you use FO or HTML+CSS as intermediate vocabulary for the purpose of displaying XML content in a browser. I believe it's fairly entrenched now that HTML is used for online browsing and FO for generating paper copies via PDF or PostScript.
--Joerg Pietschmann on the XSL List mailing list
XQuery Blueberry DOM
Entity parser dot-com
Abstract schemata
XPointer errata
Infoset Unicode BOM
--Richard Tobin on the xml-dev mailing list
There once was a man from Nantucket,
Who gave us an XML bucket
into which we have thrown,
abstruse specs, overgrown
Alas, it now seems we must chuck it.
--Jeff Lowery on the xml-dev mailing list
W3C XML Schema is a wretched combination of too big and simultaneously underspecified, with an amazing capability for creating apparently unsolvable interoperability problems.
--Simon St.Laurent on the xml-dev mailing list
There is less of a dilemma here than meets the eye. The W3C has developed such a powerful brand name that its imprimatur on a technology is extremely valuable. If the W3C takes a strong line favoring only RF patents, the patent owners will toe the line.
--Tim Bray
Read the rest in XML.com: Patents and Web Standards Town Hall Meeting
XQuery 1.0 is essentially XPath 2.0 plus
1) element and attribute constructors
2) function definitions
3) strong typing
Of course (1) is available in a different form in XSLT 1.0, and (2) is available in XSLT 2.0, so you could say that apart from syntax, XQuery is XSLT plus strong typing minus template rules.
--Michael Kay on the xml-dev mailing list
Subscriptions kill links and undermine the usefulness of search engines -- the two main ways users explore and find a richer Web beyond the sites they've bookmarked.
--Jakob Nielsen
Read the rest in User Payments: Predictions for 2001 Revisited
until someone comes up with a language with simple SELECT-DELETE-UPDATE semantics, XML databases will be the OODBMSs of the new millenium. I remember being introduced to XML and thinking that the concepts behind relational databases were more complex than those behind the hierarchical structures that encompass XML, amazingly enough the W3C has proved me wrong by producing increasingly complex languages that supposedly deal with handling XML in databases yet have much less functionality than a simple language like SQL.
--Dare Obasanjo on the xml-dev mailing list
Every time the XML community uses SGML and ISO as a whipping boy for its frustrations, the privatization of XML and the markup technologies by the commercial interests represented by the W3C increases. We complain about embrace and extend but don't notice that often we are making that possible with ill-considered tactics.
--Claude L (Len) Bullard on the xml-dev mailing list
Now that XPath 2.0 has been expanded to include most of the features of XQuery (with the rest already in XSLT), is a separate query language really needed anymore? Will anybody ever be able to implement XPointer now?
--Joe English on the xml-dev mailing list
Intriguingly, I sat near a member of the W3C Schema working group on a plane a couple of years ago, and he was reading the Worse is Better essay (apparently it was "assigned reading" for the WG). I wonder what they concluded from the assignment; it would appear that most recent W3C activities are the antithesis of Worse is Better. Simplicity is being sacrificed for correctness and completeness, and specs are held up for years while they try to sort out consistency. This is obviously the Right Thing to do, but does it take XML down the same road to oblivion that LISP traveled? Time will tell ...
--Mike Champion on the xml-dev mailing list
The XML 1.1 suggested rules seem a retreat from rationality into lazy committee thinking of piling on special cases.
--Rick Jelliffe on the xml-dev mailing list
Quotes in 2001 Quotes in 2000 Quotes in 1999