Holden wrote:
Bowerbird wrote:
x.m.l. fans here should read yet another dose of harsh reality, this time surprisingly from one of your leaders, simon st. laurent: http://www.xml.com/lpt/a/2006/03/15/next-web-xhtml2-ajax.html
it's interesting how simon uses the past tense for many of your buzzwords...
The article you post is irrelevant to current XML-based plans for PG. The whole point of the article is that direct delivery of XML to users with stylesheets has not yet happened.
The difficulty of adapting other-than-HTML XML documents to web browsers is that web browsers are largely limited, by historical development (and the resultant inertia of the installed-base of web browsers), to the HTML "paradigm." CSS partially helps with presentational "interpretation" of many XML elements using the CSS 'display' property. But CSS 'display' does not include values (nor should it for reasons best explained another time) for the following important "bread and butter" web features: 1) hypertext linking 2) image and multimedia embedding There's also the issue that using CSS 'display' to recognize table markup must be of the HTML table model. In addition, the HTML paradigm does not natively handle the TEI <note> and DocBook <Note> elements (and similar constructs found in *many* established markup vocabularies *except* HTML) which essentially place annotative content in the main flow of the text at the point of reference. Such annotative content is not intended to be displayed as part of the main flow of the document, but to be extracted and somehow rendered outside the mainflow. (CSS2.1 may be used to float and move such inline annotative content, but there's no native recognition in HTML of such inline annotative content -- it's one of the bigger mistakes, and understandable given the time I suppose, that the original HTML folk made when they invented HTML and built rudimentary browsers which essentially locked-in how web browsers are to work. They probably thought that since the annotative content can be placed elsewhere and linked to using <a>, why support inline annotative content? It was probably programming expediency more than anything.) XLink was primarily designed to be a vocabulary-independent way to add hypertext linking and image/multimedia embedding to XML documents (I think it could also be used for inline annotative content, but this is less appealing for various reasons.) Unfortunately, since everyone has been using HTML for so long, and HTML already provides the <a>, <img> and <object> elements, there's been little incentive to add XLink support to browsers. A sort of Catch-22 situation. Mozilla/Firefox support a limited subset of XLink sufficient to enable hypertext linking as the following demo will show (of course, the link only works using Mozilla-based browsers): http://www.windspun.com/demoxml/demolink.xml Unfortunately, the full XLink spec is quite complex (because it was designed to do everything except maybe toast bread) and this has acted as a further impediment to its embracement. There are quite simple subsets that could be implemented though, and implementation is fairly straightforward, even of the full XLink. XLink is implemented in several XML-based applications, but except for the limited Mozilla support as described above, XLink has not yet reached the web browser world. (Note that CSS2 may be used to embed images within XML documents, but this is a kludge since this violates the general principle of separation of content from presentation (markup should be used to embed the images, which are content, and not use CSS since documents need to stand alone without CSS -- that is, no content references should be placed into CSS -- lose the CSS, lose content.) For an example using CSS for this purpose, which works only in Opera and Mozilla/Firefox: http://www.windspun.com/demoxml/embedimage.xml ) Handling non-HTML table models is a more complex issue, and one which has no easy answer except either conforming all table markup in XML documents to the HTML model (where CSS 'display' may then be used for visual presentation), or adding multi-table-model support to web browsers. Inline annotative content is also a pretty sticky area. The XHTML 2.0 folk appeared to be close to adding something like the TEI <note> tag to XHTML 2.0, but it appears they backed away from that, I suppose because of the inertia of the current installed base of web browsers. (This can be handled by CSS2-aware web browsers by simply setting certain CSS properties for default handling.) At one time I had a demo illustrating how to get inline annotative content to be displayed to the side (such as in a sidebar), but I can't find that demo. :^( (Second note: XML Namespaces is a mechanism by which HTML markup may be embedded within XML documents. So one could add something like <xhtml:a>, <xhtml:img>, and <xhtml:object>, but then these are not vocabulary-independent ways to add such functionality. XLink is the better long-term solution because it is XML-generic.) Anyway, the bottom line is that the biggest impediment to visual presentation of "arbitrary" XML markup in web browsers is not XML, but of the inertia of web browser developers to implement a few small things, such as XLink support (even a subset sufficient for hypertext linking and images/multimedia embedding.) There's nothing inherently bad about XLink that makes it difficult to enable -- it's simply one of those Catch-22 things, combined with some "political" aspects I won't go into here.
However, from what I've heard about current PG uses of XML, they tend towards using XML as a master format for storage on the server. Content is then converted to the user's desired format (plain text, HTML, XML, PDF, or random format X).
Yes. I observe that the main thrust these days in both PG and DP is to develop a well-defined (constrained) subset of TEI for markup. XSLT can then be used to generate web-browser friendly XHTML markup, as well as other formats, such as plain text. Except for the issues of hypertext linking, image/multimedia embedding, table models, and inline annotative content as discussed above, TEI itself may be natively rendered in advanced CSS2-aware web browsers (such as Opera and Mozilla/Firefox). And as noted above, one has some limited ability to use CSS to float inline annotative content from the main flow to somewhere outside the mainflow. (Damn, wish I could find that example illustrating this.) Here's a couple CSS stylesheets already developed for rendering TEI: http://xml.web.cern.ch/XML/www.tei-c.org/Stylesheets/ (Been looking for examples of using these style sheets in action, but haven't found any yet. Anyone?)
On a slight side note, I don't see the point of your aggressive posts to the list. Everybody here should be (is?) aiming towards the furthering of PG's goals. If whatever format you choose happens to preferred in the long run, that's not a reason for gloating. The other people on this list are merely trying to help PG as much as we all hope you are.
Well, Bowerbird believes mastering PG/DP texts in XML is a bad idea, so he's trying to convince PG/DP to instead embrace regularized plain text, notably his ZML system. He's using all the weapons he can muster. I don't see using ZML for mastering, but I do see using ZML rules for regularizing the plain text output from a transformation of the XML master. Jon