[
Lists Home |
Date Index |
Thread Index
]
> Which is better: using a set of specific elements or a generic element
> with a type attribute?
Though I hesitate to express it in such terms on a list that's crawling with
philosophers, I tend to fall back on an Aristotelean distinction: if it's
part of the essence of a Fee that it is either an OrangeFee or a YellowFee,
then use distinct element names; if it's an accidental property, use an
attribute. So I would use <Dog> and <Cat> rather than <animal
species="Dog"/> etc; but I would use <Program author="mike"> rather than
<MikesProgram> and <JanesProgram>. Of course that still leaves you with
cases that are difficult to decide, of which yours might well be an example.
Some indicators:
(1) if a property can change its value over time, then it's accidental
rather than essential
(2) if the set of properties applicable to an object depend on whether the
object is an X or a Y, then the distinction between X and Y is probably
essential.
These rules can create some surprises, for example (1) says use <person
type="employee"> rather than <employee>, because a person might be an
employee one day and not the next.
There's another orthogonal (and thus potentially contradictory) indicator,
which is that it's probably easier to extend the set of values of an
attribute than to extend the set of permitted element names. So if
<OrangeFee> and <YellowFee> are two members of a set whose membership is
likely to grow over time, there's a case for using an attribute.
XSLT match patterns can handle both forms equally well. However, XQuery and
XSLT 2.0 type declarations (e.g. for variables and functions) can
distinguish <Cat> from <Dog>, but they can't distinguish <animal
species="Cat"> from <animal species="Dog">. So using different element names
will give you stronger type checking.
Michael Kay
http://www.saxonica.com/
>
> Here is a snippet of an XML document using the specific elements
> approach.
> <Fees>
> <OrangeFee><Amount>12.34</Amount><More>...</More></OrangeFee>
> <YellowFee><Amount>56.7</Amount><More>...</More></YellowFee>
> </Rate>
>
> Here is a similar document, using a generic element with a type
> attribute.
> <Fees>
> <Fee type="Orange"><Amount>12.34</Amount><More>...</More></Fee>
> <Fee type="Yellow"><Amount>56.7</Amount><More>...</More></Fee>
> </Rate>
>
> Background: We are using XML schema to specify the structure of a set
> of XML documents.
> The XML is the payload in a web service; it is described by WSDL and
> sent using SOAP. Currently it is just a message; it is not
> stored in an
> XML database. Currently the XML is written and read using
> Java. Schema
> validation is only done in test environments, not in
> production. Each
> type of value is optional, and can occur at most once. For
> any omitted
> type the Amount is treated as being 0. All names and examples are
> fictional. The type attribute uses an enumeration. The XML Schema
> fragment for that approach includes something like:
> <xs:simpleType name="FeeType">
> <xs:restriction base="xs:string">
> <xs:enumeration value="Orange"/>
> <xs:enumeration value="Yellow"/>
> </xs:restriction>
> </xs:simpleType>
>
> Questions:
> The names "set of explicit elements" and "generic element with a type
> attribute" are clear but verbose.
> Q1a. Is there a generally accepted way to refer to these approaches?
> Q1b. What other names are (or have been) commonly used?
>
> Q2. Is there an already existing writeup that discusses the pro's and
> con's of each approach?
> (This seems analogous to the elements vs. attributes discussion.)
>
> Differences:
> Here are some differences between the approaches. However, it is not
> clear how much these actually matter.
>
> Benefits of the specific element approach:
> * Allows schema to enforce at most one occurrence.
> * Allows schema to enforce sequence.
> * Allows schema to have different annotation, e.g. documentation, for
> each different type.
> * Allows different types to have different default values.
>
> Benefits of the specific element approach:
> * Is slightly easier to define the XML schema
> * Is slightly easier to modify the XML scheme, e.g., to add a new type
>
> However there may be other considerations, and some may be more
> important than these.
> Q3. Which requires less code to implement? (Is this
> different for write
> vs. read?)
>
> Q4. Which has less impact to the code after adding a new type.
> (However, adding new types will be rare.)
>
> Q5. Which has been performance?
>
> Q6. To ease the burden on the reading code we might want to
> always have
> a value for each type, populating the Amount element with 0.
> Is this a
> good idea? Does this affect the best way to represent this
> information?
>
>
> Thanks,
> Steve
> ---
> Steven Tolkin
> There is nothing so practical as a good theory. Comments are
> by me, not
> Fidelity Investments, its subsidiaries or affiliates.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
