Peter Donald wrote:
> On Sun, 8 Sep 2002 14:49, David W. wrote:
>
>>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).
>
>
> I like. So say we were going to declare a dependency of one component on
> another component. You would write it something like
>
> <dependency key="some-service" type="o.a.a.SomeService" optional="true">
> <attributes>
> <attribute name="secure" value="true"/>
> </attributes>
> </dependency>
>
> Which saids that a dependency of type SomeService, looked up using key
> "some-service" is optional. It also has extra metadata associated with it
> indicating that it must be the "secure" version of this service.
The golden rule is that elements are for content and attributes for
meta-content.
This is quite easy to understand in XHTML, where the text you see is in
element content, while the attributes specify extra info.
Now, given that xml property files are all about meta-content, I
personally really like the all-attribute approach, using elements for
multiplicity and containment, as in the above example.
I would also use the element contents to describe what the element is
about; this makes it possible to have comments everywhere, and a user
can read the descriptor as a document; it's also easy to make
documentation out of it.
<dependency key="some-service"
type="o.a.a.SomeService"
optional="true">
This Component has a dependency to o.a.a.SomeService because it
need to... and this is optional because...
<attributes>
Maybe in the future it's possibel that it will
also have... but noy there is only 1 attribute.
<attribute name="secure" value="true">
It has to be secure, because...
</attribute>
</attributes>
</dependency>
This is generally known as "literal programming".
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
