Hi Sarah!
> In general I agree that the attribute model for adding new data in our > manifests makes them more extensible. However, there are tradeoffs with > this approach, in particular with data that if mis-specified, could be > potentially destructive. For example, with AI, if we made partition info > an 'attribute' on the "target element" as opposed to a node in our > schema, this means that if not found, or if mispelled or something like > that in a manifest, the client, in this case AI client, would have to > decide what to do since the data is missing. This could cause a > potentially destructive act, if the user really wanted to preserve a > partition but mistakenly misspelled the attribute name. Part of the > design decision to use rng, and to make everything in it a real > element(as opposed to attributes on an element) was so that our parser > could do strong validation. Good to know. I agree that some action must be taken if mandatory information is missing. It's just a discussion about which tools you would leverage to detect that information is missing, and where you would provide defaults from. > This has approach has downsides. > > > Stephen mentioned SMF profiles and property groups. This works well for > SMF, and a property that is mistyped in a profile simply isn't going to > be understood, but I can't think of cases where this misunderstanding > causes destructive behavior. Order in these property groups do not > matter either, but in the case of AI, say a create and a delete of > partition data could make a big difference if not ordered correctly. We > can certainly address this within the AI client, by impose an order on > these. I just point this out to help clarify the complexities in the > installation environment. This does clarify things. > What I am looking at now is how to balance our need for strong > validation, with using attributes where they could be used, and not > cause destructive behavior. I am also look at xsd schema, in particular > the use of mustUnderstand and/or mustIgnore and namespace to provide the > extensibility we need, with the strong validation we also need. Unfortunately I haven't left the DTD world yet, so I am no expert on RNG. So I can't really follow you in this paragraph. I certainly would give up some usability if it meant better validation. > What you and Stephen have said is all true. It isn't as straightforward > in the install environment though to just do this, and it is taking a > bit of thought and design to try to do this correctly. I also have to > consider the impact of derived manifest capability and what kind of > errors could be introduced with this as well. I see. Obviously I have a narrower focus: I would like to pull data out of -- say, a ConfigDB -- and then generate manifests. Or I would like to read in a manifest for infrastructure reports. Or I would like to clone an AI server, making some adjustments to the data on the clone target. Etc. And I want to spend as little effort as possible doing it. :-) It's good to read about your considerations, since they make the design clearer for me. Thanks! Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ 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
