Hi all!
Sorry that I missed commenting in this discussion earlier. I am now trying
to catch up.
> > With this proposal, the grammar of the AI manifest is also being visited
> > to shorten element/tag names where possible. Because we're proposing the
> > usage of dynamic manifest scripts to reference nodepaths from the AI
> > manifest,
> > having shorter, simpler names makes this easier to use. In addition to this
> > reason, there are currently elements who's names unneccessarily include its
> > heirarchical parent element name again. For example,
> >
> > <ai_target_device>
> > <target_device_name>
> > <target_device_type>
> > <target_device_vendor>
> > <target_device_size>
> > ...
> > ..
> >
> > could be simplified to
> >
> > <target_device>
> > <name>
> > <type>
> > <vendor>
> > <size>
>
>
> I like this. I will keep this in mind with the AI/DC Manifest schema
> rework I am doing. This would translate well to use for both DC and AI.
Sorry, but this really hurts my eyes. And how are you distinguishing
the <name> element in another context? This will be one ugly DTD. :-)
I would much rather see a generic key/value object tree that can
be nested. Such as:
<node name="ai_target_device">
<attr name="name">namegoeshere</attr>
<attr name="type"> ... </attr>
<attr name="vendor"> ... </attr>
<attr name="size"> ... </attr>
<node name="some_child_of_ai_target_device">
<attr name="some_attr"> ... </attr>
</node>
</node>
One might even go to the extreme of adopting Apple property lists.
Software to parse this would be much easier to maintain, and
the abstraction is much clearer.
Just my personal taste...
Regards -- Volker
--
------------------------------------------------------------------------
Volker A. Brandt Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/~vab/
Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45
Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
