[
Lists Home |
Date Index |
Thread Index
]
On 3/13/06, Nathan Young -X (natyoung - Artizen at Cisco)
>
> It's not a hard and fast rule but if you are tempted to ask weather you
> should use the common element name and qualify it using an attribute
> then your probably should.
>
> If you generalize fees but capture fee color in an attribute, you can
> ask questions about either all fees or only yellow fees. What you want
> to avoid is having to parse an element name using string functions in
> order to answer questions about yellow fees.
>
I really like your answer, but I'm afraid I'm going to have to
disagree what appears to be the basic premise (and then agree with
your conclusions anyway).
One can invert any name/attribute based model so that attributes (and
in the case of XML, name spaces) are used to identify common members
of a set. As you state, you do want to avoid having to do string
parsing to find all the fees. However, adding a type attribute (eg.
in this case type="fee") or a name space (eg, fee:yellowFee) quickly
gets you around this issue for distinct element names. If in fact if
you have a Schema that identifies a common base type for yellowFee and
orangeFee you've also got the capability for doing this kind of
identification, but of course that means using the schema at all
points in the processing, which has other issues (and it sounds like
the original questioner wanted to avoid).
Personally, in general, I'd still have to stick with the advice to
build the XML element semantics based on the semantics of the rest of
the system and use attributes, name spaces and schema types to model
other relationships as needed. The qualification being, that there's
a lot of fudge factor in the phrase "in general" when it comes to XML
modelling; much of it introduced by the extent to which your system is
open or closed or influenced by external factors such as standards...
<snip/>
> Also don't underestimate the semantics surfaced by choosing an attribute
> name. If I look at a few fees of the form:
> <OrangeFee/>
> <YellowFee/>
> etc...
>
> I might assume you are modeling fee colors and assume that other fees
> might be BlueFee, BlackFee, etc.
>
> If I see fees like this:
>
> <Fee urgency="orange"/>
> <Fee urgency="yellow"/>
>
> I might infer that other fees would be green and red, and that I would
> do well to pay attention to the red fees.
Now you're getting to the issue of what do the semantics of the rest
of the system look like. IOW you're back to good old fashioned data
modelling, and here you're spot on....
--
Peter Hunsberger
|
