Hi Ethan,
The thought behind this is derived manifests will be collapsing
one XML document (the manifest provided by the AI server) and some data
(whatever we're using to derive the manifest). XML provides for XSLT to do
this merge and provides quite a rich language to describe the logic for
doing the merge (full arithmetic, logic and string processing). The
really nice thing about using XSLT is that our XML parser can validate the
all the XML and further that we don't need to provide an arbitrary
scripting environment simply an XSLT environment provided by our parser
(such as what LXML provides us already).
This would require that there's some way to manipulate the data
we're deriving off of to XML which is pretty trivial be it from a
database, flat files, etc. and I think we could provide "connectors" or
examples but otherwise customers could do what fits their environment
best.
Thank you,
Clay
On Thu, 21 Jan 2010, Ethan Quach wrote:
>
>
> On 01/21/10 14:23, Clay Baenziger wrote:
>> Further, what about the use of XML for the scripting language for
>> derived manifests?
>
> (Haven't had a chance to get to your other comments yet) but can you
> elaborate on this a bit?
>
>
>> I haven't seen any discussion about the merits of us
>> trying to stick to one technology versus what a difference technology
>> buys us.
>> Thank you,
>> Clay
>>
>> On Tue, 19 Jan 2010, Dave Miner wrote:
>>
>>> On 01/19/10 03:31 PM, Ethan Quach wrote:
>>>>
>>>>
>>>> Dave Miner wrote:
>>>>> On 01/15/10 09:32 AM, Jan Damborsky wrote:
>>>>>> On 01/15/10 09:40 AM, Ethan Quach wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 01/14/10 14:59, Dave Miner wrote:
>>>>>>>> I think we talked about most of this yesterday, except for this one:
>>>>>>>> ...
>>>>>>>>>> - I'd think we'd want to be able to self-identify a particular
>>>>>>>>>> manifest
>>>>>>>>>> as regular or dynamic without relying on an extra metadata file
>>>>>>>>>> (point 2
>>>>>>>>>> under 2.1). I must admit that I'm not quite sure why we'd need to
>>>>>>>>>> make
>>>>>>>>>> this distinction, though.
>>>>>>>>>
>>>>>>>>> Self-identifying was definitely a goal, and I'm glad you brought
>>>>>>>>> it up
>>>>>>>>> since I
>>>>>>>>> did want to discuss this a bit. One way I'd thought it could be
>>>>>>>>> done is
>>>>>>>>> to use
>>>>>>>>> the heuristic of detecting an XML file vs. a script file, but
>>>>>>>>> wasn't
>>>>>>>>> sure that'd be
>>>>>>>>> a solid enough way to determine the difference and be able cover
>>>>>>>>> the
>>>>>>>>> precise
>>>>>>>>> error cases of misinterpretation of one over the other. But maybe
>>>>>>>>> I was
>>>>>>>>> just
>>>>>>>>> over thinking that bit.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'd think you could just try to read it first as XML, it'll fail to
>>>>>>>> validate, and then you fall back to script. And if that fails,
>>>>>>>> you're
>>>>>>>> dead in the water :-)
>>>>>>>
>>>>>>> This sort of the describes the imprecise error handling I'm referring
>>>>>>> to. If we just simply try it as both, i.e. if it didn't work as xml,
>>>>>>> and didn't work as a script, what's our failure path?
>>>>>>>
>>>>>>> I'm thinking we do need to make a decision up front, heuristically or
>>>>>>> not.
>>>>>>
>>>>>>
>>>>>> I think that we need to know in advance also for being able to provide
>>>>>> correct
>>>>>> feedback to the user - one of goal of syntactic validation might be
>>>>>> to help
>>>>>> user understand which portion of the manifest is considered incorrect
>>>>>> and why
>>>>>> in case that manifest does not validate.
>>>>>> For those purposes, we would need to know that we validate what user
>>>>>> believes is XML manifest.
>>>>>>
>>>>>
>>>>> Sure, but I would expect you'd get distinguishable errors from an XML
>>>>> parser between the case of "this isn't an XML document" and "this XML
>>>>> document has missing/incorrect elements" and that would tell you which
>>>>> way to go.
>>>>
>>>> That's probably true, but I think it depends on the parser;
>>>> our current parser (on the server anyway) doesn't seem to
>>>> present anything telling me it knew this isn't an XML document
>>>> when given a plain script.
>>>>
>>>> Error: File /tmp/s failed validation:
>>>> Start tag expected, '<' not found
>>>>
>>>> which I'd presume would also be an error that can be gotten
>>>> if it actually was an XML document, but with a malformed
>>>> tag later in the document. It'd seem incorrect to even try to
>>>> run this as a script in the latter case.
>>>>
>>>>
>>>> but anyway, so what I'm hearing is that self-identification is
>>>> desirable. I'll fold this into the design. And yes, this should enable
>>>> the use of derived manifest (as currently proposed in this design)
>>>> outside of being used with an AI install service.
>>>>
>>>>
>>>> (using the file(1) command does report if a file is an XML
>>>> document, even with malformed xml in the middle of the
>>>> document, but only if its dtd. (probably looks at the header
>>>> line). rng is always reported as text.)
>>>>
>>>
>>> Yes, the rules in /etc/magic are:
>>>
>>> 0 string <?xml XML document
>>> 0 string <?XML XML document
>>> 0 string <?Xml XML document
>>>
>>> Some updates there to identify our manifests (probably in combination
>>> with putting some identification before the CDDL block) would be a
>>> good idea.
>>>
>>> Dave
>>> _______________________________________________
>>> 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
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
