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
