Re: [xml-dev] Best Practice: Element with data or element with childelem

[Evan Lenz <evan@evanlenz.net>]

I have to concur with David's critiques, but I think I can generalize 
the point you're trying to make: data-driven code is cool. The less your 
code has to know about individual names in the input data, the more 
general it can be.

However, in practice, I find that data-driven transformations are 
overrated. I'd rather design an XML structure that fits well with the 
data. For example, I'd want to use attributes when I know the value will 
only ever be text. And then I'd prefer clear, elegant code using a 
combination of generic rules ("data-driven", if you like) and rules 
using hard-coded names, especially as they make explicit my intentions.

Purely data-driven code is ugly boilerplate. I'd only make special XML 
design concessions for data-driven processing when the input contains a 
huge list of properties (such as when being dumped from a database).

Evan Lenz
http://lenzconsulting.com


David Carlisle wrote:
>> which approach is better, an image element that contains the location of a GIF file:
>>
>>    <image>images/mighty_oj.gif</image>
>>
>> Or, an image element that contains a child element, which contains the location of the GIF file:
>>    
>>     <image>
>>         <src>images/mighty_oj.gif</src>
>>     </image>
>>     
>
> At that level of generality, without knowing anything about the rest of
> the document these approaches are identical (just rename image to foo and
> src to image  in the second example). So it's impossible to make any
> comparison.
>
>
>   
>> Likewise, which is better, a retailer
>>     
> Clearly that's just the same example with different element names.
>
>   
>> Using the second approach all this information can be provided in the
>> XML document: 
>>     
>
> It can be provided somewhere in either solution.
>
>   
>> The XSLT is not hardcoded to add a specific set of attributes;
>>     
>
> Of course it is! It has the hardcoded assumption that someone has gone
> to the trouble of designing an xml format with exactly the same
> attribute names as html but using elements rather than xml attributes. 
> I suppose it's possible someone has done that but unlikely.
>
> Far more likely is they just use the same attributes in which case you
> can just use <xsl:copy-of select="@*"/> or that the element names are
> different to the html attribute names in which case you need to encode
> a translation table in your conversion and "hardwire" specific names in
> the source and result document.
>
> In any case any features you can do with the second form you can clearly
> do with the equivalent 1st form, it just depends where the additional
> metadata is placed
>
> <imagedata>
>    <image>images/mighty_oj.gif</image>
>    <alt>...</alt>
> ...
> </imagedate>
>
> for example.
>
> David
>
>
> ________________________________________________________________________
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is:
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>
> This e-mail has been scanned for all viruses by Star. The service is
> powered by MessageLabs. 
> ________________________________________________________________________
>
> _______________________________________________________________________
>
> 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
>
>