Hi Clay.
On 05/18/09 12:33, Clay Baenziger wrote:
> Hi William,
> Since I'm not very familiar with Manifest Serv. are you asking for the
> ability to do an XPath[1] style searching of elements?
> For example, if I want every documentation tag in a document under an
> element tag, I could do something like:
>
> query=relaxng_schema_doc.xpath('//element/documentation')
> for elem in query:
> print elem.tag
> print elem.text
He wants to get the text of children under an elem. He wants to group
values of multiple children under an elem together.
The code underlying ManifestServ can already do this. ManifestServ needs
only to bubble this capability up to the surface so that callers of
ManifestServ can use it.
Thanks,
Jack
>
> Thank you,
> Clay
>
> On Mon, 18 May 2009, William Schumann wrote:
>
>> Jack,
>> I'm writing to offer some suggestions on XML parsing in response to
>> your meeting minutes.
>> Associated data:
>> XML allows information to be associated, but there is no interface
>> for the XML parser to return information in an associated way. For
>> example, in a AI manifest that has more than one slice action, all
>> parameters associated with a particular action should be returned in
>> a single call. (Some of you are aware that ai_manifest.defval.xml is
>> inappropriately used to compensate for this.) The installer makes
>> extensive use of name-value pair lists using libnvpair(3lib) for C.
>> Python and other languages have the notions of associative arrays and
>> data objects, and the parser should be able to return associated data
>> in support of any languages that will use the XML parser.
>>
>> Sematic validation:
>> This could be done in a separate library so that it can be used by AI
>> both on the client and on the AI server. The semantics will be
>> identical on both.
>>
>> William
>> Jack Schwartz wrote:
>>> HI everyone.
>>>
>>> Minutes of this meeting are posted at:
>>> http://www.opensolaris.org/os/project/caiman/auto_install/AI_mtg/Minutes/XML_parser_rework_minutes_090515.txt
>>>
>>>
>>> Thanks,
>>> Jack
>>>
>>> Jack Schwartz wrote:
>>>> Hi everyone.
>>>>
>>>> I'm calling a meeting for tomorrow to discuss XML parsing redesign.
>>>> Now that we have the problem statements worked out, I'd like to
>>>> discuss and get group buy in on concepts from which a strawman
>>>> design proposal can be drawn.
>>>>
>>>> Friday 10/15, 12:30 PST, 13:30 MT, 15:30 ET
>>>> Toll Free Dial In Number: (866)545-5227
>>>> Int'l Access/Caller Paid Dial In Number: (215)446-3648
>>>> ACCESS CODE: 7385082
>>>>
>>>> We have tons to cover, so the meeting may go for two hours.
>>>>
>>>> Agenda:
>>>>
>>>> Problem statement 2: Current AI manifests are not easy to use:
>>>>
>>>> To discuss:
>>>> - Role of SMF enhanced profiles vs XML in specification
>>>> - Split input between them? (if yes, then how?) Use one or the
>>>> other?
>>>> - need to consider clarity of the files, consistency with other
>>>> utilities, other things?
>>>> - How derived profiles can be leveraged
>>>>
>>>> Problem statement 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.
>>>>
>>>> To discuss:
>>>> - How to do versioning between schema and manifest
>>>> - How to handle version mismatches between schema and manifest
>>>>
>>>> Problem statement 4: Semantic validation is needed for AI.
>>>> - Lack of it means failures further down the installation process
>>>> instead of up front, or misconfiguration.
>>>>
>>>> To discuss:
>>>> - Options for semantic validation.
>>>>
>>>> Problem statement 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.
>>>>
>>>> To discuss:
>>>> - What are the holes
>>>> - What to do about them
>>>>
>>>> Problem statement 1: AI's multiple parsers present unneeded
>>>> complexity and unmaintainability.
>>>> - Things to consider for a single parser:
>>>> - functionality for data retrieval and search, schema compatibility,
>>>> how supported / maintainable is the parser
>>>>
>>>> To discuss:
>>>> - Parser options, advantages and disadvantages.
>>>> - In light of the other preceding discussions, hopefully a parser to
>>>> choose will be apparent.
>>>>
>>>> Thanks,
>>>> Jack
>>>>
>>>
>>> _______________________________________________
>>> caiman-discuss mailing list
>>> caiman-discuss at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>
