[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Typing and paranoia
mc@x... (Mike Champion) writes: >> That's a lot of why I'm talking less and less about XML and more and >> more about markup. > >Yup. Well, I don't blame you ... and I hear similar frustrations from >the "data" side about the constraints that XML syntax handling >imposes. The "data" and "sevices" people with their infosets and >datatypes and requirements for millisecond-timeframe XML instance >processing certainly create challenges. On balance, I would prefer >to preserve and refine what is common in the center so that APIs, >schema languages, query languages, etc. can be shared across both >communities. But I certainly respect the hypothesis that the path of >least resistance is for the communities to fork. I think that forking is both necessary and useful, and it might in fact let the two communities communicate better both internally and with each other. While XML is capable of operating as a data format, it was never designed to meet the kinds of criteria that data-oriented developers typically demand, as you note above. The kinds of solutions that frequently seem obvious to data-oriented developers seem counter-intuitive or outright broken to me, even when I'm working on "strictly data" applications of XML. Right now, it seems that most XML spec development is in the hands of people with a data-centric mindset, intent on shoveling strong typing, envelopes, and global identifiers into every spec they can. The kindest words they seem to have for those of us who think that's completely inappropriate to markup are "you don't have to use it. Now get out of the way." (The other dominant faction at the W3C seems to believe that slapping a URI reference on everything directly or indirectly is the best way to make things better, another perspective that seems senseless but which is even harder to avoid.) Let's get the hell out of each other's ways. The sooner, the better, preferably in an orderly way, with well-established bridges. A flexible set of tools that lets the must-have-typed-data-as-fast- as-possible folks do their work without the overhead of XML seems like a good idea on its own merits - preferably a toolset standardized in an open process without intellectual property constraints and with multiple interoperable implementations. A clearly-defined process for converting between that format and an XML format, even a somewhat grotesque XML format, would be even better. (Think of it as a filter you can insert between the data and an XML parser, letting you treat it as XML even though it ain't.) The ASN.1 folks have been doing some work in this direction, though I have to confess that I still find their work difficult to understand, much less write anything resembling a parser for. The W3C seems at the moment to be pushing for XML throughout their specs, without much direct consideration of alternatives. The Infoset seems to be the point that people who want something more keep pushing, though with limited success. >That may well be what's going to happen, for a lot of reasons -- >nobody can get passionate about muddy compromises, so the center >often does not hold. I see the current everything-piled-into-XML as a "muddy compromise", and suspect that the weight of that compromise may be what crushes the center eventually. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com -- http://monasticxml.org
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|