Re: [xsl] xslt readability/maintainability

[Mike Brown <mike@xxxxxxxx>]

Zack Brown wrote:
> I find it difficult to come up with a consistent coding style for XSLT.
> It seems that some form of indentation and line-break decisions would be
> useful, but exactly what rules to follow for maximum readability seem hard
> to determine. Has anyone given serious thought to this problem? I'm in a
> situation where multiple people may start sending me patches for my xslt files
> (and accompanying makefiles), and I want to have some guidelines to give them,
> so the files don't become spaghettified.

I suppose it depends on what you mean by spaghettified.

At Fourthought, we have been using the convention of 2-space indents (no tabs)
for any XML or HTML, including stylesheets. Newlines are LF only, a fairly
arbitrary decision, but one that is enforced nevertheless. Encoding must be
utf-8 or iso-8859-1, and preferably will be all us-ascii, using numeric
(decimal or hex) character references for the non-ASCII characters. Attribute
value quoting we usually don't care too much about. Because Python tends to
use single quotes, some of us use those more than double, but anymore I'm
seeing a pretty random mix in documents.

In the 4Suite test suites, when we need to compare the content of XML
documents (expected output of a transformation vs actual output, without
regard for lexical decisions), we often parse the results into a DOM as a sort
of poor-man's canonicalization. Then we can walk the DOMs and compare nodes,
rather than comparing bytes in serialized output. This eliminates situations
where you would otherwise have <foo a1="a&#x31;" a2="a&#x32;"></foo> being
treated differently than <foo a2='a2' a1='a1' />, even though they are
semantically identical.

You might be running into similar situations with your colleagues' patches,
where the lexical flexibility of XML makes the patches semantically correct
but written completely differently. While <foo></foo> vs <foo/>, attribute
order, and attribute value quoting differences are fairly tolerable when they
happen, a patch that is full of whitespace changes can be annoying and is
actively discouraged (through admonishment of the offending party, mainly),
although rarely is it a real disaster. The only real danger, IMHO, lies in
encoding differences; you don't want a utf-8 encoded patch going into an
iso-8859-1 file.

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  resume: http://skew.org/~mike/resume/


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