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

[Ihe Onwuka <ihe.onwuka@gmail.com>]

On Tue, Apr 9, 2013 at 7:25 PM, Simon St.Laurent <simonstl@simonstl.com> wrote:
> On 4/9/13 1:59 PM, Ihe Onwuka wrote:

>
>
> We've defined both domain knowledge and programming as specializations.
> Schemas have largely proven to be their own specialty, fitting comfortably
> with neither of those.
>
> There are paths forward, however, using documents for the conversation.
> Examplotron is a particularly brilliant bridge to this, but it doesn't even
> have to be that formal.
>
> I have yet to find a domain expert who couldn't figure out XML document
> syntax and express "make it look like this".
>
> Similarly, in the JSON world, a lot of the conversations revolve around what
> HTML resulting from a particular transfer might look like. (Even if HTML
> isn't the intended context, it's easier to discuss than JSON directly.)
> While that does require some further conversation to move from angle
> brackets to curly brackets, I haven't heard of major missteps in the
> translation.
>
>
>> Alternatively let those with the requisite domain knowledge design
>> business rules, and if these people happen not to be programmers by
>> trade (as is often the case) then you need to come up with a language
>> they can communicate their specifications in such that all
>> stakeholders can participate in the design process. A programming
>> language is not the right vehicle for that and typically that suggests
>> that a programmer is not the right person to do it.
>
>
> I think markup - as samples - is a better choice for this kind of
> conversation than schema languages.
>

That doesn't scale and is a problem displacement.

You now have to devise a scheme for managing the information you've
dispersed ( which instance "documents" which nuance) and you have to
explain it to all your stakeholders. Some stakeholders will inevitably
end up reviewing alot of information in instances that is not relevant
to their use case and subtleties will get mired and lost in the
information dispersal.

This is as industry that does like to do this sort of substitution.
Some in the test driven community have decided that unit tests
constitute an executable specification. If I may indulge in an
anecdote.

Someone close to me recently decided to homeschool their 6 year old
child citing objections to the institutionalised nature of the
education system (bureacracy?).  Seeing as it was the child who would
ultimately bear the consequences of this decision I spoke to a friend
of mine who had won the National Teacher of the year award the
previous year. He said it was a really bad idea and told me to invite
the parents and their daughter to spend the day with his class in his
school.

I asked whether he was going to talk to the parents about their
decision. He said "No, but I'm going to show them all the things we do
in school that they would have to replicate if their child is not
going to be disadvantaged" (The child by the way kept saying "I want
to go to school").

Of course the value of things we use and do should be challenged but
here there appears to be alot of work to do before we can say that the
X in this case can substitute for Y.