[
Lists Home |
Date Index |
Thread Index
]
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
|
