[xsl] Design culture (Was: Designing XML for XSLT)

[Trevor Nash <tcn at melvaig dot co dot uk>]

I originally wrote:
>>I can not influence the content of this source document.
>
> I've lost count of the number of times I have seen this, most
> commonly with grouping type questions. Anybody got a theory as to
> why this happens? There must be thousands of person-hours being
> wasted.

Jeni wrote:
>When people design markup languages, they can't always predict every
>use the information in the XML documents will be put to, plus they
>don't necessarily know the strengths/limitations of every method of
>processing the document. (It would be straightforward to sum amounts
>with units using DOM or SAX, for example.)
>

The question was a bit rushed, let me try to make myself clearer.

I wasn't really thinking about how the poor designs got there in the
first place (BTW the XML that sparked this thread off isn't bad in
itself, it just happens to be awkward to deal with in XSLT).

 I was wondering why, having identified a weakness in a design, people
seem to find it impossible to get the design changed.  Of course
design changes should never be taken lightly, but I have always
thought it a strength of XML (and XSLT more so) that it has an
inherent flexibility missing from many other ways of constructing
software.  Am I wrong?

My own pet theory is that we are seeing a kind of throwback to
database design.  It really is a nightmare to change a database
schema:- so much so that organisations pay people (DBAs) to make it
hard to make changes.  Are they doing the same with XML
Schemas/DTDs/whatever without realizing that there is no need?

The reason I think this is important is that this kind of
social/pschological/organisational problem is much more likely to kill
a language than any sort of technical flaw.

How poor designs get there in the first place is also a good question,
and might have the same kind of answer.  Can it be just lack of the
right skills?  If so, I'm available!

Jeni wrote:
>Does anyone know of a set of guidelines for designing markup languages
>for processing with XSLT? If not, it could be a useful resource to put
>together somewhere. Things like:
>
> - keep numbers and units separate
> - be consistent in case use in attribute/element values
> - use namespaces to embed HTML in XML, not CDATA sections
>
>Any others?

Yup.  Don't design markup languages specifically for XSLT ;-)
(Jeni more or less said that in her intro, but I couldn't resist)

Regards,
Trevor Nash
--
Traditional training & distance learning,
Consultancy by email

Melvaig Software Engineering Limited
voice:     +44 (0) 1445 771 271 
email:     tcn@melvaig.co.uk

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list