Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
