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
JComponentclass, for example. It has well over 200 methods.JButton, as aJComponentsubclass, 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 "busines