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.
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.
- - -
>
> 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".
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090528/44a9dc72/attachment.html>
