[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Where is XML going
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 12 Dec 2010 21:37:56 -0500
Henri,
At the risk of starting an argument here (not that any of us would do that ;-) I suspect the problem comes with the definition of open, which is, to put it somewhat ironically, very open to interpretation.
In general, open source software tends to hew closely to a single architect's vision of what should and should not be within the domain of the application, even when that architect is no longer explicitly involved in the day to day building of the software. This holds for browsers as much as it does any other software category, and certainly it can be argued that for a number of reasons (some of them pragmatic, some of them ideological) most browsers have had a focus that's been mainly javascript-centric, that's seen HTML as being a language separate from and only marginally related to XML, and that has comparatively little use for the XML viewpoint, beyond the acknowledgement that one could represent HTML5 using an XML syntax. There are historical reasons for that certainly, having less to do with whether a given technology is or is not appropriate and far more having to do with who was doing what at what stage of development of a given product.
For many of those people working in the XML space, the evolution of HTML5 in particular has become frustrating, because there has generally been very little attempt on the part of the HTML5 working group to reach out to the XML groups and find points of commonality. The discussions that have been ignited in the past couple of weeks in great part by James Clark's blog post have raised some critical questions - are there points where XML and JSON can coexist or overlap, are there ways that XML can be introduced as a first class data type in line with strings, numbers and arrays, are there things that the XML community can do to help bridge the domain between the client world and the server one? I for one was a big champion of E4X, which i believed had a potential to BE that bridge, but that direction was cut short on the Mozilla side, and was never taken up elsewhere beyond ActiveScript (admittedly in part due to the resistance on the part of certain other browser vendors).
To my way of thinking - and certainly this is not representative of everyone on this mailing list - I think the question that perhaps needs to be asked is this: What would it take to get the HTML5 working group to consider incorporating the core XML technologies at their current levels - XSLT2, XPath 2, XSD 1.1, possibly XQuery, as well as a bridge technology such as E4X, into the HTML5 specification? This does not mean making HTML elements XPath accessible (though I think this would be fantastic) - this simply means providing the necessary foundational hooks within the specifications to incorporate these technologies as a baseline. it would simplify the Javascript code when working with XML (which is not going away, anymore than JSON is), it would give developers the ability to work with time tested technologies that meet their needs, and overall it would make such applications more responsive to a broader set of needs, which is one of the major benefits that any browser technology has.
Regarding the closed nature of the XSLT2 discussion at TPAC, I don't know for sure. Certainly, the discussions regarding XSLT2 have been available on a public forum as is the case with most W3C standards in development. My suspicion is that the issues may have been due to a need to discuss potential patent conflicts, but I'd refer such questions directly to the XSLT working group. I do know that the HTML5 group has been similarly closed about both its development proposals and about involvement beyond a fixed group of people, most of whom share one particular interpretation of what HTML should be. Having said that, I think it ill-serves either group to ignore the other, when each has so much to offer.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Sun, Dec 12, 2010 at 7:49 PM, Henri Sivonen
<hsivonen@iki.fi> wrote:
On Dec 4, 2010, at 15:41, Michael Kay wrote:
> The ONLY reason for doing it on the server is that the server is an open platform while the browser is a closed platform. So fix that problem.
How do you define "open platform"? You can run any JavaScript program in browsers without App Store -like restrictions, so the browser platform is an open platform in the sense Windows is one. There are two Open Source browser engine implementations, so the browser platform is an open platform in the sense Linux is one. The relevant specs are defined in public. (Contrast this with XSLT WG which was the only group at TPAC marked confidential *and* marked as not accepting observers. http://www.w3.org/2010/11/TPAC/Schedule )
--
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
