Hi everyone.
Here is a recap of the problem statements for XML parser rework, as
discussed last week at our meeting and with some follow-on email today:
1) AI's multiple parsers present unneeded complexity and
unmaintainability. (Note: at the meeting we settled on "Determine
parser requirements" but I have since realized that this was not a
problem statement.)
- Things to consider for a single parser:
- functionality for data retrieval and search, schema compatibility,
how supported / maintainable is the parser
- The right parser will fall out as the other problems are solved.
2) Current AI manifests are not easy to use.
- Fragmented, could be better organized
- We decided that changing from XML is out of scope and off the table.
3) AI manifests need to be forward and backward compatible between builds.
- Manifests of different versions than the automated installer must
work whenever possible.
- A given version of the automated installer must be able to
recognize a manifest with which it is not compatible and gracefully fail.
4) Semantic validation is needed for AI.
- Lack of it means failures further down the installation process
instead of up front, or misconfiguration.
5) AI manifests have validation holes.
- Example: criteria schema doesn't bind a min/max pair of ipv4 address
patterns to an ipv4 address criterion.
Moving on to design:
1) On "Current AI manifests are not easy to use:"
I propose the following to start the discussion. For simplicity, a
single manifest containing criteria, ai_manifest content and sc_manifest
content can be used. All content would be represented in a single xml
format. This allows for less fragmentation and more straightforward
organization when possible. It also can prevent major changes which
could occur if a datum was switched between one format to another.
The AI can process the material however it sees fit. This can include
creating XML files of other types based on some of the materials if it
needs to interface with other tools. This approach allows for changes
in what is done with the data, without having to change the schema. For
example, if a DTD is created now with some of the data, and then later
some new mechanism replaces what uses the DTD, the DTD info can be
switched out for the new format without the user ever having to know
about it. This helps future compatibility.
There are benefits of having separate files which would be missed if
only a single file was allowed. Having separate AI manifest and SC
manifest can allow for the same basic install to be done, but have
different user and other configuration information on each system. I
propose that the fields in the manifest can have a pointer to another
file which has the information that field would contain. A second file
can have several fields defined, each pointed to by their respective
fields in the first manifest. For example, the first manifest of two
different kinds of systems may have a username, username password and
root password fields set to point to the second manifest, where they
would be defined. Each kind of system would be installed based on
their manifest, but would have the same user information as they both
point to the same second manifest. The complication of a second
manifest would be used only when needed, allowing for more complex
setups, but not robbing the simple setup of a simpler manifest file
configuration.
This may have implications on testing, as there would be a larger matrix.
Thanks,
Jack
