* Sarah Jelinek <Sarah.Jelinek at sun.com> [2010-02-02 13:47]: > Hi Volker, > > On 02/ 1/10 01:30 PM, Volker A. Brandt wrote: > >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. :-) > > > > We are using relaxNG as the schema. So, it wouldn't be an ugly DTD. > But, possibly an ugly relaxNG :-). The <name> element is > distinguished by its parent. Unless I am missing your point. > > >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. > > Why would software to parse this be easier to maintain?
Because if you need another attr type for a node, you need only to change your parser, not your schema. If you change your schema, then you will find that older systems can't parse newer manifests. (That is, schema versioning becomes an issue.) - Stephen * Is it really necessary to prefix entities with "ai_" * You might find that the property_group and property entities in the smf(5) DTD useful, since they are designed for later extension.
