On 05/07/09 10:05, Eric J. Ray wrote:
>
> So, these still sound like solutions.
I respectfully disagree. Solutions talk about how to solve problems;
here I am presenting the problems which need to be addressed, and (OK...
with the exception of (1)), what parameters there are to consider in
selecting the right choice. I am not discussing how to solve the
problems though.
>
> What does the parser need to do? How? To what end? If we didn't have
> a parser?
>
> What problem does the parser solve? Lacking an answer to that question,
> how would we know what the right one is?
Fair enough on this one... It would have been better not to list the
"which parser" issue first. The other items being discussed will guide
a solution to the "which parser" item.
>
>
> On May 6, 2009, at 3:22 PM, Jack Schwartz wrote:
>
>> Hi Karen, Sarah, Ethan, Alok, Keith, and anyone else interested.
>>
>> I am calling a problem definition meeting on XML parsing work redesign.
>>
>> Thursday 5/7, 11 AM PST
>> Concall info: 866-545-5227 / 7385082
>>
>> If you are named above or really interested, and the time doesn't
>> work, please let me know.
>>
>> Below is the evolving list comprising "the problem we are trying to
>> solve," but I want to finish discussing this with the team and come
>> up with a final list.
>>
>> Problems to be solved:
>> =====================
>>
>> General:
>> -------
>> 1) Settle on the right parser.
>>
>> 2) Implement a schema / manifest versioning mechanism:
>> - which allows forward and backward compatibility between
>> the installer build and the manifest.
>> - Difference between versioning and extensibility;
>> importance of extensibility?
>>
>> 3) Settle on the best schema type:
>> - must be capable of supporting the other issues being
>> resolved (e.g. versionability) and no regression of
>> current support.
>> - if DTD is not used, there must be a straightforward way
>> if converting between the schema and a DTD, to support
>> SMF profiles.
>> - Importance that schema files can import other schema files?
>>
>> AI-focus:
>> --------
>> 4) Present only one schema type to the end user.
>> - Redo the AI manifests to use that schema.
>>
>> 5) Semantic validation support for AI manifest.
>> - Can we eliminate the need for a defval manifest?
>>
>> 6) Provide a way for AI to easily get parameters grouped together
>> by a common parent.
>>
>> 7) Redo the criteria manifest so that it can be more thoroughly
>> validated.
>>
>>
>> Limitation of scope:
>> ===================
>>
>> Immediate focus is specific to AI and DC, but a goal during
>> development will be to make it as generic as possible.
>>
>>
>> If there's any time left over (ha ha), we can start talking about
>> specifics.
>>
>> Thanks,
>> Jack
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
