I like mixed, myself. It isn't possible to use attributes for everything. They're really only good for simple data types. Basically strings and numbers. For one to many relationships (like declaring multiple dependancies) or complex composition (like the configuration of an entire sub-component, or a recursive definition) are only praticle with nested elements.
Attributes are good for simple, but important properties. <component name="X" impl="com.biz.X" > <displayName>The magnificent X</displayName> <description>X is a .....</description> <version>1.0.2</version> </component> I tend to think of attributes as something you can identify the node with. Properties like displayName, description, and version can and will change over time, but if name and impl are the same, you probably haven't broken anything. When you look through the entire XML file and you think, "That's the record for ____", you should make whatever value you use to identify the record (it's key basically) an attribute. Okay, now I think I've figured out what I'm trying to say. The mental database approach: make something an attribute if you might want to seach for it or use it as an identifier (after all, 'component' doesn't tell you anything). David Weitzman > On Sun, 8 Sep 2002 14:04, Peter Donald wrote: > > Hiya, > > > > I was wondering if anyone had any thoughts on the conventions we should use > > in our xml files. Essentially when should we use attributes and when should > > we use elements. > > > > One school of thought saids we always use attributes if the value can only > > appear once. The negative aspect of this is that you can get elements with > > massive numbers of attributes like > > > > <component > > name="X" > > impl="com.biz.X" > > version="1.0.2" > > displayName="The magnificent X" > > description="X is a ...." > > ... > > /> > > > > This is fairly common in document centric descriptors. > > > > Another school of though saids that you never use attributes. Like most of > > descriptors that come out of Sun. It is easier to extend, but this ends up > > with fairly verbose files like the following. The other problem is that if > > you want to validate using DTDs you end up with stupid names like > > <component-name> in an element <component> (see servlet/ejb descriptors for > > an example). > > > > <component> > > <name>X</name> > > <impl>com.biz.X</impl> > > <version>1.0.2</version> > > ... > > </component> > > > > The other pattern I have noticed is that some people prefer to store "meta" > > data about element as attributes while they store "content" data as > > elements. > > > > So any preferences among these alternatives? My current thinking is that we > > should probably go with the Sun-style (no attributes) just because it is > > more common in java world. Thoughts? > > Or maybe we go with a mixed approach because that may be the most human > readable? > > -- > Cheers, > > Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
