If feel that this is not really specific to the DOC design - and more to do with the schema design and also for the data model for targets.
As far as the DOC is concerned we just need to support the name and the ability to provide the structure, which I believe we do. Would you agree? Or do you still feel there is something that DOC needs to do here? Thanks, Darren. On 05/25/10 11:17 PM, Dave Miner wrote: > On 05/25/10 04:24 PM, Sarah Jelinek wrote: >> >> >> On 05/25/10 12:56 PM, sanjay nadkarni wrote: >>> On 05/25/10 09:39 AM, Sarah Jelinek wrote: >>>> >>>>> I think this is an improvement, though I'm hoping we can make simple >>>>> cases very concise. >>>>> >>>> >>>> I agree, but there is a tradeoff when defining a schema with regard >>>> to validation of the form of the elements and attributes which don't >>>> provide as much validation capability. I am trying to balance the >>>> need for validation with simplicity. >>>>>> This is an attempt to provide a flatter manifest. However, if you want >>>>>> to not provide the fully qualified name, you can do that as well, for >>>>>> example: >>>>>> >>>>>> <disk> >>>>>> <ctd name="c1t1d0"> >>>>>> <slice name="0"> >>>>>> >>>>>> If a user wants to do this. It isn't required but allowed. >>>>>> >>>>>> So, I think that we have to allow for both of these naming schemes and >>>>>> provide the ability to get the parent of a child to get the childs >>>>>> full >>>>>> name. >>>>>> >>>>> >>>>> Why do we have to allow for both? I'm trying to understand what >>>>> value having multiple alternatives provides. >>>> We don't have to allow both. It could be a constraint that the user >>>> must provide a fully qualified name even in this example: >>>>> <disk> >>>>> <ctd name="c1t1d0"> >>>>> <slice name="c1t1d0s0"> >>>> I think that there is flexibility in allowing the user to provide a >>>> shorthand notation. But, even if they did we could store the name as >>>> fully qualified, based on the parent. >>> Can you elaborate on what type of flexibility you are thinking of ? >>> i.e. Since all installs are on a slice (or in case of GPT a >>> partition) what's benefit in separating ctd name from slice name. >> >> Today a user can pick a disk to use. They can create, delete or preserve >> partitions and slices. So, even if they pick a disk, they may have >> additional directives for components of that disk. In this case, logical >> components of the physical disk. >> >> So, if the user chooses to name the target via a ctd name, then >> create/delete/preserve partitions for this target device, allowing them >> the ability to just give the partition number doesn't seem like a huge >> deal, and it provides them flexibility in terms of how they specify the >> target devices. >> >> I don't see a reason not to allow this type of input, even if we always >> store it as a fully qualified name in the data cache. >> > > I'm not sure the complexity is really justifiable, though. It creates > multiple modes of input we have to resolve, with concomitant expansion > of test cases (both unit and black-box) and additional documentation burden. > > If it were to allow easy cut & paste of complex strings (MPXIO anyone?), > I might think differently, but this seems almost directly the opposite > :-) I'd really like to find ways to infer the encapsulating objects if > given a slice or partition directly, so that cut & paste is easy. > > Dave > _______________________________________________ > caiman-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
