[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Not using mixed content? Then don't use XML
> That in no way justifies the "constraints first" model that has dominated > markup conversations for the last three decades. There is a saying among industrial designers: "The Problem Comes First". Modelling and developing in terms of driving forces and constraints is central to design activity as a profession. Christopher Alexander drew attention to the similarity between solutions that also shared a similarity between driving forces and constraints. In other words, your problem is most likely not very unique. And the solution will likely be a variation of an established pattern. Now, given that you've had the luck (ie wise management) to actually understand what the problem is about (business value, workflow, culture/habits, legacy, strategy, etc etc), how often would you need to start from first principles? And, even if you need to develop a vocabulary from scratch, how much trouble would it be to document your vocabulary in terms of your problem space? maybe even give it a name and a version, so that you don't introduce yet another invisible global state into your business processes? Kind regards Peter Ring On Mon, Mar 25, 2013 at 3:40 PM, Simon St.Laurent <simonstl@simonstl.com> wrote: > On 3/25/13 10:00 AM, Toby Considine wrote: >> >> Do you document the interfaces/messages that you use internally, even if >> only for yourself? > > > Yes, of course. That barely requires schemas, however. > > >> Do you write down the assumptions you make, and what might be an error, >> even >> if only for yourself, when you come back in a year? > > > It depends on the complexity of the problem, though of course you always > have to allow for the fact that distance from the code will add complexity. > > >> Is any of this documentation machine readable, to be consumed by your >> tools? > > > Probably not. How many machine readable representations do you actually > need? Worse, creating machine readable representations creates the > temptation to treat that representation as law. > > >> And when you get hit-by-a-bus (or take another job, or get bored and open >> a >> goat dairy) what happens? Or if you do not care (because you'll be off >> with >> the goats...), how do you feel about keeping those systems working when >> the >> person you rely on when exchanging forbidding stray notes, or answering >> out-of-band queries, or who has said something completely different from >> the >> vocabulary you've chosen leaves to be a maker of goat cheese... > > > You're trying to change the subject, presenting a broken culture as a sane > response to forgetfulness and loss. Sorry, but that is not an excuse. > > >> A culture of innovation a culture of compliance, or even a culture of >> straight-jacketing can all exist whether or not we use standard schemas. >> Standard schemas can coexist with ad-hoc schemas. As long as we avoid >> those >> zealots (and I know them, too) who want to extend their one schema or >> information model to be used in all other spaces, whether they fit or not, >> then the standard specifications add great value. An overbroad >> specification, or a minimal standard badly applied, can certainly reduce >> productivity and creativity. A minimal standard, well used, enhances >> creativity. > > > Constraints can be wonderful - I'm having a hard time breaking away from > writing a book because I set the right constraints for it. It has also > helped that I changed the constraints to some degree along the way. (And > that I will continue to change them in response to reader feedback...) > > That in no way justifies the "constraints first" model that has dominated > markup conversations for the last three decades. > > >> As Ed Crowley observed long ago, "There are seldom good technological >> solutions to behavioral problems". You seem to be focusing on behavioral >> problems, which can be endemic in certain organizations, and on the misuse >> of specifications. > > > Not quite. I'm diagnosing XML's role in transmitting those diseases, and > the impact that role has had on XML's acceptance and usefulness. > > Those who won't acknowledge that they are sick rarely respond well to a > diagnosis. Those who make their livings from the continuation of the > illness - well, that's even more complicated, and a key part of the problem > we've built. > > > Thanks, > -- > Simon St.Laurent > http://simonstl.com/ > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|