[sldev] Format of install.xml

[Ricky]

Hmm..  I think the best way would be to have it take in a simplified
XPath-like string EG: "//glh_linear/packages/linux64/url"  This should mean,
in XPath terms, "Find the node named 'url' who's parent is 'linux64' who's
parent is 'packages' who's parent is 'glh_linear' which is located anywhere
in the tree."  That was the kind of query I had started thinking about, but
was forced down the "following-sibling" approach.

To make this general-purpose it should also take in the file to be processed
as a parameter, or as stdin.  That way it can also be a filter.  I like
filters :D

This means that if the query returns a key who's child is a map, the
children XML structure should be echoed to stdout, perhaps with the xml
delaration and <llsd> wrapper to keep consistent.  But if the only child is
a text node, it should echo just the text.

I am not sure which of the following cases I like better for the query
"//glh_linear/packages/linux64/url":
  1: Returning: "<uri>
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-linux-20080812.tar.bz2
</uri>"
      This would mean that i would need to use the query
"//glh_linear/packages/linux64/url/text()" or similar to get to the text...
  2: Returning: "
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-linux-20080812.tar.bz2
"
      This implies that the datatype of the following node is unimportant.



On second thought....  Maybe the program should pretend the structure of the
XML file is as follows:
<?xml version="1.0" ?>
<llsd>
  <map>
    <key name="installables" type="map">
      <key name="glh_linear" type="map">
        <key name="copyright" type="string">Copyright (c) ....</key>
        <key name="description" type="string">nVidia....</key>
        <key name="license" type="string">glh_linear</key>
        <key name="packages" type="map">
          <key name="linux64" type="map">
            <key name="md5sum"
type="string">2965646aea1d2a6aec1fbc431c02733f</key>
            <key name="url" type="uri">http....</key>
          </key>
        </key>
      </key>
    </key>
  </map>
</llsd>

This would make the query:
"//key[@name='glh_linear']//key[@name='linux64']/key[@name='url']"
return: "<?xml version="1.0" ?><llsd><map><key name="url"
type="uri">http....</key></map></llsd>"

Which seems nice and consistent.  To access the text content directly the
following XPath could be used:
"//key[@name='glh_linear']//key[@name='linux64']/key[@name='url']/text()"

But I think this option, while having the prettiest logic, may be too much
to ask for... :)

Yet if the LLSD was read in, transformed internally to the above (or
similar) structure, and then the queries were run against that new
structure, it might not be too hard to implement.  All that would be needed
is a library that gives you the power of XSLT and XPath, and an XSL
stylesheet to control the restructuring.  Maybe the way to go

Only question left would be what the structure to be queried SHOULD look
like...  My suggestion above was simply based on how I saw the current
layout of the file.  Maybe the data type should be the node, not an
attribute, or maybe the name should be the node?  Some thought needs to be
spent here.

Thanks for the opportunity! (And thanks for reading this essay!!)
Ricky
aka Cron Stardust

On Mon, Jan 5, 2009 at 11:35 PM, Rob Lanphier <robla at lindenlab.com> wrote:

> On 01/05/2009 07:31 PM, Ricky wrote:
> > Thanks for the response!
> >
> > I think I will use the custom function approach.  It is fast to
> > implement (considering I already made the XPath string!) and I don't
> > yet understand enough Python... :P
> >
> > The downside is that my script is still dependent on something that
> > wouldn't normally be in the environment: The XMLStarlet package.
> >
> > I wonder... What would it take to rewrite the
> > serialization/deserialization functions so that the output XML was
> > better formed?
>
> LLSD is used in a LOT of places in the system, so it's pretty unlikely
> that we'd change the way that LLSD gets serialized to XML in general.
> Using something other than LLSD for install.xml is something that might
> be more likely, but only marginally so, I think.
>
> I might be willing to help you out with this.  If you could have a
> command line utility that pulled the right out, how would it work?
>
> Rob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090106/0220b1e7/attachment.htm