Further, what about the use of XML for the scripting language for derived
manifests? 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
>
