Jack Schwartz wrote: > On 05/28/09 11:15, Sarah Jelinek wrote: >> Hi Jack, >> >> Some general comments/questions: >> >> 1. The scope of this project is listed as: >>> The scope of this document encompasses input specifications >>> (manifests) for the Automated Installer >>> project (AI). >> >> However, later I do not see any mention beyond the 3 manifests that >> are included in this input specification list. The reason I am asking >> about this is that we had talked previously about the possibility of >> defining separate input specs for common functionality among the >> caiman installers. For example, specification for target devices on >> which to work. Both AI and DC do this today, although in different >> ways, but the commonality of the functionality allows for us to >> possibly define a 'target' input specification that can be used by >> multiple consumers. Is this no longer in scope? If not has it been >> decided that this is off the table? Or is it defined in another >> project? I can't see it related to the other projects you had listed >> in a previous email but I may be missing something. > Thanks for bringing this up. Yes, we did discuss this, but not in the > context of having separate manifests. I thought we ruled out separate > manifests thinking they would be too complicated and difficult to juggle. > > Instead, we talked about having similar sections for the same > functionality (e.g. targets) in different project manifests (e.g. DC > and AI). Manifest schemas for different projects can be put together > in a modular fashion using separate subschemas for different parts. > So, for example, assuming each project had the same "target" input > requirements, there could be a subschema for targets. I have verified > that the subschema concept works for RelaxNG. > Ok, yes, I remember this now :-). > Not sure that this is really within scope, since this deals with field > layout. That said, it does deal with XML file layouts... Anyhow, I > will add a note about it to the specification so that it is > documented. I have added this to the bottom of section 5.1, install > manifest functional description: > > - - - > Note: the install manifest schema can be set up so that different > sections are supported by different sub-schema files. These sub-schema > files would contain a mini schema (field definitions) for the section > they represent. (For example, there may be a sub-schema on target disk > setup.) A ?main? schema would reference a sub-schema file for a > section of fields, instead of directly referring to those fields. If > the sub-schema files are reused by multiple consumers, they will make > setup of their manifest section uniform across those multiple > consumers. Having different schema files for different sections allows > for a mix and match approach of different manifest sections for > different consumers. >
This makes it clearer. Thank you for adding this. > - - - >> >> 2. In this project we are specifically dealing with the AI manifests. >> Later we will deal with the parser for AI and DC and other potential >> Caiman consumers. I am wondering... is there anything with regard to >> DC and AI manifests that can be normalized with regard to the common >> input we request from users? Maybe not in this project but wondering >> if this is in scope for any other project. > This was not part of the stuff I was working on, because I was leaving > field definitions up to the individual "consumer" projects (DC, AI, etc.) >> >> Specific comments/questions on this functional spec: >>> The XML file format will contain versioning information which is >>> defined by the XML parsing >>> functional spec for the third problem statement: ?AI manifests need >>> to be forward and backward >>> compatible between builds.? >> >> This info isn't really required in this projects functional spec. > Yes, it doesn't really have much to do with inter-file items. I'll > delete. >> >> Section 5.3: >>> A Sysmap Manifest may contain zero or more sets of criteria. >> So, can a sysmap manifest contain pointers to other criteria >> manifests? Or do all criteria in the set have to be specifically be >> in the same file? > The sysmap manifest contains the sets of criteria, not pointers to > them somewhere else. I don't see a point of having a criteria set > elsewhere, since they won't be replicated. There should be only one > set of criteria mapped to a given install manifest and SC manifest > combination. So the set should be defined in the sysmap manifest itself. > > I can make this clearer by saying "A sysmap manifest contains zero or > more sets of criteria," removing the word "may". Maybe I am thinking about this in a strange way....but I was thinking that if users had separate criteria manifests, they wanted to use in combination in some way, being able to add a pointer to the criteria manifest they wanted to include for a particular service would be easier than them having to duplicate it. So, they have a 'store' of criteria manifests, which they may use in different combinations for different AI install services. sarah **** >> >> Section 6.1: >>> Derived Profiles makes configuration of each >>> system unique enough on the network to coexist with the other systems. >> >> It isn't clear to me what this statement means with regard to the use >> case it is associated with. Can you clarify? > What I meant by this is that derived profiles can dynamically generate > parameter values which are unique to each system. I'll clarify in the > document. >> >> Section 6.3: >>> This case installs systems all systems with the same disk >>> configuration and packages, but >> >> I think you mean to say 'This case install all systems with the same >> disk configuration and packages, but... > Thanks. Fixed. >> >> That's it for now. > Thanks so much again for your comments. > > Jack >> >> thanks, >> sarah >> >> >> >> >> >> >> >> >> >> >> >>> Hi everyone. >>> >>> Here is a link to a "functional specification" for solving the XML >>> parsing problem of "Current AI manifests are not easy to use." It is >>> a rough draft, and I'm posting it to verify that I am on the right >>> track. >>> >>> It deals with XML problem statement 2: >>> >>> Current AI manifests are not easy to use. >>> >>> Its scope is inter-file organization of the manifests (naming, >>> high-level structure, inter-relatedness), which is quite a limited >>> scope for a functional specification. Other redesign tasks (XML and >>> others) will tackle the fields inside the manifests. >>> >>> Please send comments / feedback by lunchtime tomorrow. >>> >>> http://www.opensolaris.org/os/project/caiman/XML_Parsing/xml_2_func_spec.pdf >>> >>> >>> >>> Thanks, >>> Jack >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >
