Cart
[Home] [By Thread] [By Date] [Recent Entries]
On 4/28/13 9:17 PM, David Lee wrote: > I agree only indirectly ... Why do I want transformations ? I don't > do it for fun. You do it for work. If the transformations go away, so do a lot of jobs. You seem to regard transformations as something you have to do, not something you want to do. What would be better to work on? > What are tools to enable clear descriptions ? One way is clear and > concise specifications, one form of which is schema. There are other > ways like putting the two people who know each format side by side > and verbally exchanging the information Or by doing it iteratively, as the conversation grows, working with approaches that don't try to limit the frequency of conversation to big bangs passing as much information as possible at once. (That is frequently the case in all these mere web applications using JSON, for instance. Non-trivial, but workable.) Transformations defining paths from "yours" to "mine" are a surprisingly good basis for those conversations, certainly more easily versioned than "ours". > ... that is if they can remember all the details perfectly. Doesn't it bother you that we actually let our tools reach the point where we just don't remember what our systems are doing? I know it's not unusual, but it's a sign that automation has gone too far. > There certainly are other ways to > solve the problem, but the problem still requires clear understanding > of format and semantics, and a rich enough data model and toolset. Clear understandings are marginally possible under the best of circumstances. Insisting on genuinely common semantics makes the tool set problems look small. > So IMHO transformations are not the advantage itself but rather the > means to an end. One part of a bigger problem which the XML > ecosystem solves fairly well, certainly vastly better then JSON, and > IMHO better than any other ecosystem currently available. But of > course by solving a big problem it suffers somewhat on simple > problems. oh well, cake and eat etc. XML likes to think it solves big problems. After a decade and a half with it, I think markup has brilliantly solved big problems (and has been since GML and friends), but the layers on top of markup have been an extended effort in solving the wrong problems. Since at least some customers want those problems solves, the ecosystem persists. Global understandings of vocabularies and content are about as good an idea as global variables, if that. (For those tracking heresies, I think that brings me closer to Walter Perry's Standard Data Vocabularies Unquestionably Harmful than I've been in the past.) But yes, we seem to agree that XML is more transformable than other stuff, though I'm sure there's something I haven't found that's even better for transformations. Thanks, -- Simon St.Laurent http://simonstl.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
