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

["Simon St.Laurent" <simonstl@simonstl.com>]

On 4/9/13 1:59 PM, Ihe Onwuka wrote:
> Developers are called on to do all sorts of things they are not
> trained to do. Designing user interfaces is another thing that is high
> on list.

I've noticed that...

> There are exceptional ones that do combine domain knowledge with
> technical ability. Good luck with finding enough of them and getting
> your organisation to pay them what they are worth so as to retain
> them.

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.

If programmers later want to inflict programming expectations of 
inheritance and reuse on the communications thus created, they will do 
it, but that madness should not be privileged as the canonical 
explanation.  I'd argue that those schemas should even stay private, as 
details specific to a particular brittle implementation than as a symbol 
of broad agreement.

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