I'm designing a new schema and have googled extensively for
reasons to
use elements or attributes to store info. The general opinion is that
removing attributes leaves the content intact. So <book
title="..."> is
wrong and <book language="..."> is OK.
The standard reference for this question is
http://xml.coverpages.org/elementsAndAttrs.html
With that rule in mind I designed a diagnostic schema that contains
configuration information like which models and software releases
experience a problem, as follows:
<problem
models="long list"
software_releases="long list"
>
instead of
<problem>
<models>
<model>...</model> (many times)
</models>
<software_releases>
<rel>...</rel> (many times)
</software_releases>
</problem>
List-valued attributes are possible, and are supported by XML Schema (and,
to a degree, in DTDs) but they always raise a question-mark in my mind.
Making the hierarchy explicit using child and grandchild elements seems in
many ways preferable.
Now my model list can be up to 50 words of 10 characters each, and my
software release list can be up to 20 3-digit releases like 3.2.1.
Q1: Is there a performance penalty for either design?
Q2: Does the answer depend on the XSLT processor?
Q1: yes. The two designs will have different performance characteristics.
Using a list-valued attribute is less work for the XML parser, but more work
for the XSLT processor. It all depends on what you're doing with the data.
However, unless you really understand your performance requirements and
workload in great detail, it's wrong to base your XML design decisions on
hypethetical performance benefits.
Q2: processing list-valued attributes gets a lot easier in XSLT 2.0,
especially if you write schema-aware stylesheets. In 1.0 it's really hard
work.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--