Re: [xml-dev] Not using mixed content? Then don't use XML

[Peter Ring <peter.ring@texo.dk>]

> 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
>