On 07/31/09 09:34, Dave Miner wrote: > Jack Schwartz wrote: >> On 07/31/09 06:31, Dave Miner wrote: >>> >>>>> >>>>>>> >>>>>>> The solution in use case 3 tries to infer format based on the >>>>>>> attributes specified, and misses existing and future options. >>>>>>> For example, it's possible to install SVR4 packages from an http >>>>>>> URL, and IPS will have an on-disk format in the future. I >>>>>>> strongly recommend making declaration of package type explicit, >>>>>>> if that's necessary, or have it automatically resolved by your >>>>>>> solution based on a recognition of the location's format (which >>>>>>> may be relatively simple). >>>>>> Good point. Better not to assume a certain format or location >>>>>> type for different kinds of packages. I think being explicit >>>>>> about the type of package is better than resolving it >>>>>> automatically for the following reasons: >>>>>> - It makes the package type explicit in the manifest, with no >>>>>> extra effort on the user's part. (Instead of "package" elements, >>>>>> we can have "IPS", "legacy" and "DU" elements to call out the >>>>>> specific types.) >>>>>> - It is more maintainable, since if some new format of a package >>>>>> is introduced, the installers won't have to be updated to >>>>>> recognize them. >>>>>> >>>>>> Additionally, it is simpler for us to implement at the outset. >>>>> >>>>> I would not use "package" elements. Perhaps call it a >>>>> "driver_bundle" or something of the sort with an additional "type" >>>>> attribute. This avoids further overloading the package term, and >>>>> limits the amount of change to the schema required for additional >>>>> types, should any future ones be needed. >>>> I changed "package" elements to "IPS", "legacy" and "DU" elements. >>> >>> That would still leave the problem of needing a schema update to add >>> additional types, though, wouldn't it? I think it would be >>> preferable to not need that. >>> >> Either way there would need to be a schema update if we add >> additional types, but it is true that the change would be less. > > I would have expected that we could leave the types as unspecified > strings and validate them in the consumer based on what it implements, > rather than making them explicit in the schema. This gets down to how much validation we want to do via the schema. If we want to use the schema to validate, then we add the correct string selections as <choice>s in the schema.
Until now, we've leveraged the schema to do as much checking as we could do with it. I still think this is a good idea. (An exception was with the AI criteria manifest, and I filed a bug on this.) If we don't use the schema to validate a field, we need to implement the check elsewhere. If we change the types field to accept another value later, we'll have to change our validation code. Seems easier to change the schema than to change our own validation code. If we don't use the schema to validate the "types" field, why not skip using it for other fields. Where do we draw the line? I still think it is good to use the schema for validation and to have <choice>s in it for the "type" field. If I'm missing something here, please let me know. > >> Looking at this with fresh eyes this morning, what I like more about >> your approach is that it is more understandable to the user. >> >> So I'll change the example to: >> <add_drivers> >> <bundle type="IPS", name="SUNWraiddev", >> location="http://myrepo";, noinstall/> >> <bundle type="legacy" name="SUNWtata,SUNWtata2", >> location="/media/usbstick/tatadir"/> >> <bundle type="DU", name="*", >> location="/media/du_volume"/> >> </add_drivers> >> > > Please use "SVR4" rather than "legacy", though, as it's precise. OK. Thanks, Jack > > Dave
