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

[James Fuller <james.fuller.2007@gmail.com>]

Simon sez'
>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.

Sorry Simon, this statement doesn't float for me (perhaps I am very
ill) ... just because XML went through a gigantic hype curve and got
to the other side, doesn't mean it is 'sick' or 'ill'.

It is far too easy with the benefit of hindsight to categorically
state how 'terrible' a certain decision was ... to take an example
from my geologist past, its like saying to Nature how stupid s/he was
when she evolved a species of snake to grow legs, lose them for a few
million to only grow them back again ... 100 million years after the
fact. I don't mind evolution and you shouldn't mind it either.

Calling it ill, broken culture or otherwise just seems like you are
bitter that XML never gained worldwide dominance ... I for one have
never seen the right technology applied by 'crowdsourcing' ...
otherwise we would have a lot more lisp programmers around. XML is
widely deployed and adopted .... move on, we have.

What I find amazing (and what Mr. Brooks was going on about) is if you
choose the right technology at the right moment you can be *a LOT*
more productive over the average approach ... to me xml technology
stack makes me as an individual very productive, but perhaps thats
because the problems I choose to use the tech on match.

Jim Fuller






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
>