On 02/02/10 10:02, Stephen Hahn wrote: > * 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.
Is there any advantage of using a DTD over just defining that abstraction in the schema? -ethan
