OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] 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

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]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS