[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] should, does, contexts
Joshua Allen bemoans the state of xml-dev: >Personally, I find it very sad that discussion of data >models is so often shouted down by self-proclaimed "markup >defenders" who interject themselves into the conversation; >but I take consolation from the fact that this situation >exists only on xml-dev. In the real world, data models >and markup coexist much more peacefully. I believe you've mistaken one of the strengths of xml-dev for a weakness, and perhaps this mistake is what makes it so difficult to give your messages the benefit of the doubt. xml-dev is one of the very few forums where XML processing is frequently discussed in a context of "how should this work?" rather than "how does this work using XYZ tool?" Data models "in the real world" are specific to given projects or inherited from particular tools, while on this list those projects and tools are mostly background to the larger questions. Questions about syntax vs datamodel aren't very important in my experience in projects where end-to-end contracts govern how processing is done, especially if a common toolset is shared. I suspect those tend to be the projects people think of as "normal", and that vision seems to be what guides the current quest for ever-stronger contracts that reach deeper and deeper into processing. Questions about syntax vs datamodel are crucial for those of us who break the contracts. Perhaps we're horrible oathbreakers or something, but I find myself breaking even the contracts used for XML inside of my employer's work on a regular basis, building my own processing chains which let me do testing and transformations well outside the usual pathways. (I spent a fair amount of this past weekend doing just this.) In that oathbreaking perspective, access to syntax is crucial and datamodels are illusions, as substantial as Platonic forms but frequently less practical. Data models certainly have their uses, and I can cope with developers who care only about data models and not at all about syntax, but I have to admit that that last part is not very much fun, as I indicated earlier [1]. Telling people to pay attention to representation details and stay away from abstractions may seem like odd behavior to people who don't care about representation, but it seems perfectly rational from the perspective of those of us who frequently throw away data models (and create new ones!) in order to get our work done. The "vs" you so repeatedly deny very clearly exists as soon as you get beyond the simple-seeming but desperately complicating assumption that everything works the same. xml-dev seems like a good home for an awful lot of those people. It was originally created as home to discuss the creation of XML tools, "s upporting XML implementation and development". A lot of the people here still create their own tools, and some of us have learned to do so during our apprenticeships here. I'm not sure you're seeing "self-proclaimed" so much as "self-selecting" or "learning". I certainly wouldn't have predicted I would hold these positions even after writing my first few books on XML, but reality intruded. [1] - http://lists.xml.org/archives/xml-dev/200305/msg00710.html
|
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
|