サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
夏の料理
blog.jclark.com
There's been a lot of discussion on the xml-dev mailing list recently about the future of XML. I see a number of different possible directions. I'll give each of these possible directions a simple name: XML 2.0 - by this I mean something that is intended to replace XML 1.0, but has a high degree of backward compatibility with XML 1.0; XML.next - by this I mean something that is intended to be a
Twitter and Foursquare recently removed XML support from their Web APIs, and now support only JSON. This prompted Norman Walsh to write an interesting post, in which he summarised his reaction as "Meh". I won't try to summarise his post; it's short and well-worth reading. From one perspective, it's hard to disagree. If you're an XML wizard with a decade or two of experience with XML and SGML bef
One of my New Year’s resolutions is to blog more. I don’t expect I’ll have much more success with this than I usually do with my New Year’s resolutions, but at least I can make a start. I have been continuing to have a dialog with some folks at Microsoft about M. This has led me to do a lot of thinking about what is good and bad about the XML family of standards. The standard I found it most ha
I spent last week in Redmond talking to Microsoft about M and Oslo. The question at the back of my mind before I went was "Does M really have the potential in the long term to be an interesting and useful alternative to XML?". My tentative answer is yes. Here's why: Although M, as it is today, is interesting in a number of ways, it is obviously a long way from being a serious alternative to XML
One part of the vision underlying RELAX NG is that validation should not be monolithic: it is not necessary or desirable to have one schema language that can handle every possible kind of validation you might want to do; it is better instead to have multiple specialized languages, each of which does one kind validation, really well. Consistent with this vision, RELAX NG provides only grammar-based
Java 1.4 introduced the java.net.URI which provides RFC 2936-compliant URI handling. I thought I should try to fix Jing and Trang to use this. So I've been looking through all the relevant specs to figure out to what extent I can leave things to java.net.URI. It's convenient to begin with XLink. Section 5.4 requires the value of the href attribute to be a URI reference after certain characters th
Rather late in the day, I sent a comment in on the proposed XML 1.0 5th Edition. For some background, read Norman Walsh, John Cowan, David Carlisle and Henry Thompson. There is a real problem here, and it's partly my fault. If we had had a bit more foresight ten years ago, we would have made the 1st edition of XML 1.0 say what is now being proposed for the 5th Edition. I know that the XML Core WG
I've had some useful feedback on my previous post. I need to take a few days to get clearer in my own mind what exactly it is that I'm trying to achieve and find a crisper way to describe it. In the meantime, I would like to offer a few thoughts about XML and JSON. My previous post came off much too dismissive of JSON. I actually think that JSON does have real value. Some people focus on the abili
What's the problem? I see the real pain-point for distributed computing at the moment as not the messaging framework but the handling of the payload. A successful distributed computing platform needs a payload formata way to express a contract that a payload must meeta way to process a payload that may conform to one or more contractsthat is suitable for average, relatively low-skill programmers,
このページを最初にブックマークしてみませんか?
『James Clark's Random Thoughts』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く