[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

• From: "Simon St.Laurent" <simonstl@simonstl.com>
• To: xml-dev@lists.xml.org
• Date: Mon, 25 Mar 2013 13:43:44 -0400

On 3/25/13 1:25 PM, Peter Ring wrote:
>> 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.

Resolving forces and constraints is what design activity does, yes.  The 
questions are more about timing and control.

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

I fear that you've chosen the wrong expert - Alexander is actually one 
of the key people to have explained to me why software's borrowing of 
the architect model is poison.

 From The Production of Houses (1985):

"The great complexity needed by a human settlement cannot be transmitted 
via paper; and the separation of functions between architect and builder 
is therefore out of the question.  The complexity can only be preserved 
if the architect and contractor are one.  All this makes clear that the 
architect must be the builder.

And the opposite is true also.  In modern times, the contractor and his 
crew are deeply and sadly alienated from the buildings they produce. 
Since the buildings are seen as "products," no more than that, and since 
they are specified to the last nail by the architect, the process of 
building itself becomes alienated, dessicated, a machine assembly 
process, with no love in it, no feeling, no warmth, and no humanity.

...it is axiomatic, for us that the people who build the houses must be 
active, mentally and spiritually, while they are building, so that of 
course they must have the power to make design decisions while they are 
building, and must have an active relation to the conception of the 
building, not a passive one.  This makes it doubly clear that the 
builders must be architects (74-5)....

Let us imagine building five hundred houses.  In today's normal method 
of building large-scale housing projects, one architect and one 
contractor often control a rather large volume of houses or apartments...

The architect-builder... has greater powers but more limited domain. 
Any one architect builder may control no more than twenty houses at a 
time, but he will take full responsibility for their design and 
construction, and he will work far more intensely with the individual 
families, and with the individual details of their houses. Thus, in this 
model of construction, both design and construction are decentralized....

Of course, this means that the architect-builders play a different role 
in society.  There are more of them - taking the place of the alienated 
construction workers and architectural draftsmen who now provide the 
manpower to make the centralized system work...

We envisage a new kind of professional who is able to see the buildings 
which he builds as works of love, works of craft, individual; and who 
creates a process in which the families are allowed, and even 
encouraged, to play their natural role in helping to lay out their 
houses and helping to create their own community. (76-78)"

Now, he may have stolen the idea roughly from Ruskin, but that isn't a 
"design a fixed schema and then let everyone go implement it" model.

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

The problem is less about the design of the vocabulary, and more about 
the structures we've built around having experts design the vocabulary 
first.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/

• References:
  • Not using mixed content? Then don't use XML
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: Not using mixed content? Then don't use XML
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • Re: Not using mixed content? Then don't use XML
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • RE: Not using mixed content? Then don't use XML
    • From: "Toby Considine" <Toby.Considine@gmail.com>
  • Re: Not using mixed content? Then don't use XML
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • Re: Not using mixed content? Then don't use XML
    • From: Peter Ring <peter.ring@texo.dk>