Hi Volker, I have some thoughts on this discussion and the other discussion we had a week ago, RE: elements vs attributes. I am working on manifest redesign/schema redesign right now for AI and DC.
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. 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. 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. 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. Regards, sarah **** On 02/ 8/10 08:32 AM, Volker A. Brandt wrote: > Sorry for the late response. I guess I should not ask questions while > on the road with only intermittent net access... :-( > > I'm trying to respond to Keith Mitchell and Karen Tung in one message. > > > Keith asked: > >>> I mainly notice this while generating AI manifests for hands-off >>> installations. This must have been discussed somewher before. >>> Just wondering... >> >> Forgive me if I'm missing the obvious, but wouldn't that partially >> defeat the purpose of having a schema in the first place? With the >> suggested form, instead of changing the DTD/schema, you just have to >> validate the content elsewhere, in a way that is less user friendly. > > Yes, I agree, the work needs to be done somewhere. I was just arguing > that adding elements was a less user-friendly and more maintenance- > intensive process than providing a fixed schema, and add data whenever > an extension is necessary. > >> Remember, the new elements are optional, so they shouldn't affect any >> manifests that don't want/need to make use of the new feature. > > Agreed. However, you would need to update the schema in the first > place. This is what I'd rather avoid. > > > Karen said: >>>> Why are these new elements added? On first glance, they might seem >> >> These new elements are added to allow users to specify a root password, if >> they wish, for the image they are constructing. They are done this >> way following the style of the rest of Distribution Constructor >> manifests. > > I fully agree. I did not clearly phrase my original question, sorry. > I should have asked why this is all done in form of elements. There > must have been a design decision at some point. > >>>> user-friendyl with their "descriptive" names. OTOH, it creates quite >>>> a bit more work when you want to validate or generate such manifests. >> >> Why is it more work to validate it? You define what you want to >> validate in the schema, and >> it will be taken care of. > > Here is what Stephen Hahn said in another thread about a very similar > question of mine: > > http://opensolaris.org/jive/message.jspa?messageID=455158#455158 > > In essence, the work is better spent in the parser/validator than in > the DTD/schema. I am not saying your XML style is broken or less > usable than any other style, just that it might lead to more work > in other areas. It is clear that you defined these elements following > the established pattern. > > > Regards -- Volker
