From s-thapa-11@alumni.uchicago.edu Sat Sep 1 15:49:17 2001 From: s-thapa-11@alumni.uchicago.edu (Suchandra Thapa) Date: Sat, 1 Sep 2001 09:49:17 -0500 Subject: [Catalog-sig] Status In-Reply-To: <057001c12bf3$5c653b30$ae03a8c0@activestate.com>; from andym@ActiveState.com on Thu, Aug 23, 2001 at 09:47:53AM -0700 References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com> Message-ID: <20010901094917.C1623@hepcat> --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 23, 2001 at 09:47:53AM -0700, Andy McKay wrote: > Just wondering what the status of the catalog-sig, whats the plan for mov= ing > forward, and what can I do to help? >=20 > Looking at the status it looks like we had two prototypes one in Zope (li= nk > not working) and another that I havent looked at installing yet. But after > that activity seems to have stopped... >=20 I have some code that has limited functionality. Currently it has a text interface, has a basic system for specifying package and server information, can deal with dependencies, and there is currently some ftp code but I haven't tested that yet. I've been meaning to work on it but=20 have gotten busy earlier. I need to add more documentation and change some of the code around to make it easier to understand. I'm in the midst of mo= ving but I should get some time to put some work on it later, and should be able= to post an alpha version here on Tuesday, possibly earlier. =20 The biggest problem I came across when writing the code was a lack of a= =20 catalog for locating information about installed packages. Without that it= =20 becomes very difficult to handle dependencies in more than a rudimentary=20 fashion. I know this was discussed on the distutils sig but I'm not sure w= hat=20 the current status on this is. Also a listing of files in a package would be important if we want to let users delete packages but is not necessarily (C= PAN current seems to do okay without a delete function). The other area we problem need to consider is package maintenance on sy= stems that have a package manager. I believe distutils allows you to generate rp= ms from a package so it should be too difficult to integrate this with rpm bas= ed distributions. I don't think other package formats like debian or slackware are support by distutils so it would be more difficult to integrate into t= hose systems. =20 Also I'm not sure how well windows could be supported. Pure python=20 packages shouldn't be a problem but packages that have c or c++ files to be compiled would probably need to be distributed as a binary since gcc, vc++,= =20 and/or swig probably won't be available. How does disutils work on windows? =20 --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuQ9WwACgkQ6nShCjt5AZIc9ACfQ6M6yCZWCVVUBM4Z4/NwAZJf xEsAoIje+hbyKdHivJad84qm7VTwNuH6 =PQnx -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From martin@loewis.home.cs.tu-berlin.de Sun Sep 2 16:54:34 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Sun, 2 Sep 2001 17:54:34 +0200 Subject: [Catalog-sig] Status In-Reply-To: <012c01c12ccb$e7128b60$ae03a8c0@activestate.com> (andym@ActiveState.com) References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com> <200108231918.f7NJIMs07607@odiug.digicool.com> <00ce01c12c28$04485dd0$ae03a8c0@activestate.com> <200108240102.VAA02194@cj20424-a.reston1.va.home.com> <012c01c12ccb$e7128b60$ae03a8c0@activestate.com> Message-ID: <200109021554.f82FsYu04691@mira.informatik.hu-berlin.de> > Probably, what I need is a vision. I havent got one yet. Then just take mine :-) "Make the registry for Python packages operational for production use". I'd like to see the registry operate somewhere at python.org, but that is not mandatory - what matters more is some sort of guarantee that data put in won't be lost, and that there are no downtimes of the service longer than, say, 24h. It may be that it won't be used once it is there; in this case, I can offer the follow-up vision "talk package maintainers into putting their software into the registry, and to update the entry every time they update the package". These people would be "early adaptors", so you not only have to talk them into using the system, but also to deal with all the problems they find. Regards, Martin From andym@ActiveState.com Mon Sep 3 18:29:07 2001 From: andym@ActiveState.com (Andy McKay) Date: Mon, 3 Sep 2001 10:29:07 -0700 Subject: [Catalog-sig] metadata References: <20010831183938.51696.qmail@web11608.mail.yahoo.com> Message-ID: <00a001c1349d$f0374b70$ae03a8c0@activestate.com> > I spent some time looking at the metadata of some > other packaging systems namely Debian's apt, ACS's > apm, and the OSD format. Yep, we use the OSD format quite well in the perl and python packager manager. > there is also an assumption within the pep241 and 243 > i'd like to address. namely that the author of a > package will be the person to upload a package. at > least initially this is likely to be unlikely, > especially during an initial rush to fill up the > repository via some semi-automated extraction from the > vaults. You're absolutely right, this was an issue we had with our catalog. > something else i was considering is a some type of > global unique identifier to allow for replication of > information to different repositories. i was thinking > of something along the lines of a new uri protocol > that identified a package on the basis of its > classification with the catalog... i'm a little fuzzy > on this. You probably dont want to make it unique on the classification since that may change. CPAN uses authors, which isn't too bad but we will be a little less strict on that. Wouldn't the combination of package name and version be good enough and reasonably permanent? Cheers. -- Andy McKay. From guido@python.org Tue Sep 4 01:06:44 2001 From: guido@python.org (Guido van Rossum) Date: Mon, 03 Sep 2001 20:06:44 -0400 Subject: [Catalog-sig] Status In-Reply-To: Your message of "Sun, 02 Sep 2001 17:54:34 +0200." <200109021554.f82FsYu04691@mira.informatik.hu-berlin.de> References: <057001c12bf3$5c653b30$ae03a8c0@activestate.com> <200108231918.f7NJIMs07607@odiug.digicool.com> <00ce01c12c28$04485dd0$ae03a8c0@activestate.com> <200108240102.VAA02194@cj20424-a.reston1.va.home.com> <012c01c12ccb$e7128b60$ae03a8c0@activestate.com> <200109021554.f82FsYu04691@mira.informatik.hu-berlin.de> Message-ID: <200109040006.UAA04435@cj20424-a.reston1.va.home.com> > > Probably, what I need is a vision. I havent got one yet. > > Then just take mine :-) "Make the registry for Python packages > operational for production use". Exactly. > I'd like to see the registry operate somewhere at python.org, but that > is not mandatory - what matters more is some sort of guarantee that > data put in won't be lost, and that there are no downtimes of the > service longer than, say, 24h. I can't talk for XS4ALL, but I expect that this won't be a problem. > It may be that it won't be used once it is there; in this case, I can > offer the follow-up vision "talk package > maintainers into putting their software into the registry, and to > update the entry every time they update the package". > > These people would be "early adaptors", so you not only have to talk > them into using the system, but also to deal with all the problems > they find. I doubt that finding early adopters would be a problem. Dealing with the problems they find is of course essential for the success. --Guido van Rossum (home page: http://www.python.org/~guido/) From martin@loewis.home.cs.tu-berlin.de Wed Sep 5 08:01:21 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Wed, 5 Sep 2001 09:01:21 +0200 Subject: [Catalog-sig] metadata In-Reply-To: <20010831183938.51696.qmail@web11608.mail.yahoo.com> (message from Kapil Thangavelu on Fri, 31 Aug 2001 11:39:38 -0700 (PDT)) References: <20010831183938.51696.qmail@web11608.mail.yahoo.com> Message-ID: <200109050701.f8571Lr01769@mira.informatik.hu-berlin.de> > I've started work on a fourth catalog implementation. > I've had a few questions/comments, i wanted to send to > the list to resolve regarding metadata. While this is a laudable goal, I have a few procedural concerns with your message. > the key for interoperability among the three is having package > metadata. More specific, the key for interoperability is having *standard* metadata. > looking over pep 241, i can note several deficiencies > that i would like to address. While the use of rfc822 > for metadata definition does lower the author burden > is unextensible and creates the opportunity for > ambiguity in the metadata, i'd like to change this to > an xml based format. This is where my procedural concerns start. PEP 241, as-is, is already implemented in distutils and currently available to users through Python 2.2aX. Any change at this point in time needs a *very* good reason for the change, such as the PEP being unimplementable, not achieving the goal it is intended to achieve, etc. IOW, changing the format of the metadata now will significantly slow down progress on producing a catalog implementation, and getting packages registered with it. Thus, we might get the perfect system on paper; I'd rather prefer an incomplete system in reality. As for XML specifically: What problem does the mere switching to XML achieve? I believe your claim that the current format is unextensible is incorrect: The Metadata-Version was put in precisely to allow future extensions. I'd strongly discourage "proprietary" extensions at this time, so not being able to put in those is a good thing: Any extensions used ought to be published and documented, in a revision of PEP 241. > probably the biggest problem with adoption of pep241 > is the lack of dependency info. Dependency info should > be both version specific and capable of being os > dependent. Because package dependency is really hard, I believe it was deliberately left out from version 1.0 of the metadata. That means that any package author requiring prerequisite packages should put the prerequisite list into the Description, with the user of the catalog being responsible for fulfilling the prerequisites. So lack of dependency info is IMO a key to success, rather than a problem. > there is also an assumption within the pep241 and 243 > i'd like to address. namely that the author of a > package will be the person to upload a package. at > least initially this is likely to be unlikely, > especially during an initial rush to fill up the > repository via some semi-automated extraction from the > vaults. That's a good point. Should we support a Packager field in addition to the Author field (which, of course, requires a new Metadata-Version)? Alternatively, would could encourage uploaders to put their name into the Author field, and put the "true" author into the Description. I doubt the true author would be happy to receive complaints about the packaging when she didn't even know somebody uploaded the package. That also relates to the question how package uploads get approved; that is something that whoever operates the catalog needs to find a policy for. E.g. some uploaders could get permission to upload packages they didn't author (you can find out the signer of a package from the signature, right?) > i'll try and write up an xml schema which defines this > package-metadata xml format. Before you do so, I'd like to hear more what problems you expect to be solved by an XML format over the PEP 241 format. Regards, Martin From rnd@onego.ru Wed Sep 5 18:03:33 2001 From: rnd@onego.ru (Roman Suzi) Date: Wed, 5 Sep 2001 21:03:33 +0400 (MSD) Subject: [Catalog-sig] Status In-Reply-To: <200109040006.UAA04435@cj20424-a.reston1.va.home.com> Message-ID: On Mon, 3 Sep 2001, Guido van Rossum wrote: >> It may be that it won't be used once it is there; in this case, I can >> offer the follow-up vision "talk package >> maintainers into putting their software into the registry, and to >> update the entry every time they update the package". Can't SourceForge infrastructure used for managing Python Catalog? This will solve many problems, as many packages are at home at SF anyway. So they could do it virtually linking entries into Catalog (without stroing thing double). Just an idea... I really do not know what SF _can_. >> These people would be "early adaptors", so you not only have to talk >> them into using the system, but also to deal with all the problems >> they find. > >I doubt that finding early adopters would be a problem. Dealing with >the problems they find is of course essential for the success. Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/ _/ Wednesday, September 05, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "... Clinton sandwich: $5 of baloney and $20 in taxes" _/ From mats@laplaza.org Thu Sep 6 08:45:26 2001 From: mats@laplaza.org (Mats Wichmann) Date: Thu, 06 Sep 2001 03:45:26 -0400 Subject: [Catalog-sig] Status In-Reply-To: References: <200109040006.UAA04435@cj20424-a.reston1.va.home.com> Message-ID: <5.1.0.14.1.20010906033600.0453f108@204.151.72.2> >Can't SourceForge infrastructure used for managing Python Catalog? This >will solve many problems, as many packages are at home at SF anyway. So >they could do it virtually linking entries into Catalog (without stroing >thing double). Just an idea... I really do not know what SF _can_. Dunno, but I'll take a look at it sometime. I had suggested in a different forum that we maybe needed a site for little packages, that were not big enough for their own SF projects...some of those maybe coming out of the now deleted "contrib" directory from python.org. Tim Peters suggested setting up a single SF project as a container for all these smaller bits. Don't know well this would work without exploring further. From guido@python.org Thu Sep 6 10:32:12 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 06 Sep 2001 05:32:12 -0400 Subject: [Catalog-sig] Status In-Reply-To: Your message of "Thu, 06 Sep 2001 03:45:26 EDT." <5.1.0.14.1.20010906033600.0453f108@204.151.72.2> References: <200109040006.UAA04435@cj20424-a.reston1.va.home.com> <5.1.0.14.1.20010906033600.0453f108@204.151.72.2> Message-ID: <200109060932.FAA01263@cj20424-a.reston1.va.home.com> > Dunno, but I'll take a look at it sometime. I had suggested in > a different forum that we maybe needed a site for little packages, > that were not big enough for their own SF projects...some of those > maybe coming out of the now deleted "contrib" directory from > python.org. Tim Peters suggested setting up a single SF project as > a container for all these smaller bits. Don't know well this > would work without exploring further. Another alternative would be to revive use of the starship.python.net site for this. --Guido van Rossum (home page: http://www.python.org/~guido/) From k_vertigo@yahoo.com Fri Sep 7 06:24:42 2001 From: k_vertigo@yahoo.com (Kapil Thangavelu) Date: Thu, 6 Sep 2001 22:24:42 -0700 (PDT) Subject: [Catalog-sig] metadata In-Reply-To: <200109050701.f8571Lr01769@mira.informatik.hu-berlin.de> Message-ID: <20010907052442.35461.qmail@web11603.mail.yahoo.com> --- "Martin v. Loewis" wrote: > > I've started work on a fourth catalog > implementation. > > I've had a few questions/comments, i wanted to > send to > > the list to resolve regarding metadata. > > While this is a laudable goal, I have a few > procedural concerns with > your message. allright. > > the key for interoperability among the three is > having package > > metadata. > > More specific, the key for interoperability is > having *standard* > metadata. definitely. > > > looking over pep 241, i can note several > deficiencies > > that i would like to address. While the use of > rfc822 > > for metadata definition does lower the author > burden > > is unextensible and creates the opportunity for > > ambiguity in the metadata, i'd like to change this > to > > an xml based format. > > This is where my procedural concerns start. PEP 241, > as-is, is already > implemented in distutils and currently available to > users through > Python 2.2aX. Any change at this point in time needs > a *very* good > reason for the change, such as the PEP being > unimplementable, not > achieving the goal it is intended to achieve, etc. the pep is obviously implementable, the question is rather does it achieve its goal, the pep itself doesn't define a goal, so that is hard to say. as for achieving my goal as stated previously as """ creating a pythonic version of cpan/apt, to automate installation of new packages with depedency resolution. """ the pep as it currently stands make such a goal IMO pratically unattainable/maintainable. therefore the sooner changes are discussed and made, the better. > IOW, changing the format of the metadata now will > significantly slow > down progress on producing a catalog implementation, > and getting > packages registered with it. Thus, we might get the > perfect system on > paper; I'd rather prefer an incomplete system in > reality. two things, regarding slowing down catalog implementations, i think changing the format of the metadata so that it can achieve the above goal, will affect just the opposite, namely to speed up catalog development by providing standard metadata needed to provide the interfaces suggested in the catalog-sigs in addition to additional services like subscriptions and syndication. second, please understand that it is not my desire to mandate any changes to existing peps or guidelines. i want to create a real world extensible system that can be used and tested before asking for pep revisions and or authoring new peps , as per my interpretation of pep guidelines from pep 1 """ The PEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the PEP. """ i intend to conduct development openly in this forum with key draft documents available for review. i sincerely want to have a real world implementation that can be adapted to existing standards and allow for open implementations of a client (for example an rdf based client). what i've stated in my metadata comments reflect my thoughts on an information set that i will be using internal to the server and client. making this infoset standard will ease both development and maitainenace. if upon completion of this catalog server these changes are ill-recieved i can hack up some conversion. the server should also allow manual addition of such information via web interfac. also a real world implementation fufills the original comments to the recent 'status' thread for an implementation as well. > As for XML specifically: What problem does the mere > switching to XML > achieve? I believe your claim that the current > format is unextensible > is incorrect: The Metadata-Version was put in > precisely to allow > future extensions. I'd strongly discourage > "proprietary" extensions at > this time, so not being able to put in those is a > good thing: Any > extensions used ought to be published and > documented, in a revision of > PEP 241. what does xml provide... generic language indepedent processing tools for heirarchical information thats amenable to internationalization and is easily extensible. all of which are standard "xml benefits" items ( i feel like i'm preaching to the choir:). the real question is what do rfc822 headers provide, very little imo. simple processing via standard module and low developer overhead. xml parsing routines are also standard in the library and the format is also text editable albeit not quite as friendly as rfc822 headers but with a developer tool/module this is mitigated. modeling some of these concepts in straight rfc822 headers yeilds some fairly ugly results that can be ambigious. the cumulative benefits for implementations of catalog servers and clients seem overwhelming to me. > > > probably the biggest problem with adoption of > pep241 > > is the lack of dependency info. Dependency info > should > > be both version specific and capable of being os > > dependent. > > Because package dependency is really hard, I believe > it was > deliberately left out from version 1.0 of the > metadata. That means > that any package author requiring prerequisite > packages should put the > prerequisite list into the Description, with the > user of the catalog > being responsible for fulfilling the prerequisites. > > So lack of dependency info is IMO a key to success, > rather than a > problem. i think we might have different core goals. to me depedency info is a must. leaving it out of the standard and to convention violates your stated principal above of using 'standard metadata'. without depedency info i think there is undue burden on client and server implentations for depedency resolution (both for install, upgrade, and removal). in addition, the catalog itself should be maintaible, shifting the burden to a few maitainers of the catalog from the masses of the python developers will make a catalog implementation *much* harder to maintain and populate. this info should properly be designated by those who know the packages namely their maintainers and authors. as for depedency info being hard, i'd really like some feedback for my metadata schema ands it characterization of depedency info. sadly emailing this will have to wait till tomorrow when i get back from vacation and have a real net connection. > > there is also an assumption within the pep241 and > 243 > > i'd like to address. namely that the author of a > > package will be the person to upload a package. at > > least initially this is likely to be unlikely, > > especially during an initial rush to fill up the > > repository via some semi-automated extraction from > the > > vaults. > > That's a good point. Should we support a Packager > field in addition to > the Author field (which, of course, requires a new > Metadata-Version)? > Alternatively, would could encourage uploaders to > put their name into > the Author field, and put the "true" author into the > Description. I > doubt the true author would be happy to receive > complaints about the > packaging when she didn't even know somebody > uploaded the package. i would be much more in favor of Packager field rather than introducing non obvious semantics into common metadata concepts. cheers kapil thangavelu __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From martin@loewis.home.cs.tu-berlin.de Fri Sep 7 07:41:48 2001 From: martin@loewis.home.cs.tu-berlin.de (Martin v. Loewis) Date: Fri, 7 Sep 2001 08:41:48 +0200 Subject: [Catalog-sig] metadata In-Reply-To: <20010907052442.35461.qmail@web11603.mail.yahoo.com> (message from Kapil Thangavelu on Thu, 6 Sep 2001 22:24:42 -0700 (PDT)) References: <20010907052442.35461.qmail@web11603.mail.yahoo.com> Message-ID: <200109070641.f876fmf01404@mira.informatik.hu-berlin.de> > second, please understand that it is not my desire to > mandate any changes to existing peps or guidelines. i > want to create a real world extensible system that can > be used and tested before asking for pep revisions and > or authoring new peps So IOW, you want to create a competing infrastructure, hoping that it will be better than the one specified in the PEP, and that it will eventually replace the PEP. Is that correct? Then, of course, you are free to make any choice of implementation, protocol, etc., that you consider appropriate. I'm less interested in such a thing, though, since I cannot interoperate with it unless its protocol is documented. > generic language indepedent processing tools for > heirarchical information thats amenable to > internationalization and is easily extensible. all of > which are standard "xml benefits" items ( i feel like > i'm preaching to the choir:). the real question is > what do rfc822 headers provide, very little imo. Almost all of the same. Language-independence, internationalization, easily extensible. They only difference is that they are not hierarchical. > simple processing via standard module and low > developer overhead. I think processing of 822 headers is simpler than processing XML, because 822 headers are not hierarchical. > the cumulative benefits for implementations of catalog > servers and clients seem overwhelming to me. I don't share this optimism, but as I said: If you are planning your own infrastructure, go with whatever you consider appropriate. > i think we might have different core goals. to me > depedency info is a must. leaving it out of the > standard and to convention violates your stated > principal above of using 'standard metadata'. without > depedency info i think there is undue burden on client > and server implentations for depedency resolution > (both for install, upgrade, and removal). Initially, and until dependency is in the metadata, the software would not deal with dependency at all. It would be up to the user to deal with dependency. Regards, Martin From guido@python.org Fri Sep 7 13:27:51 2001 From: guido@python.org (Guido van Rossum) Date: Fri, 07 Sep 2001 08:27:51 -0400 Subject: [Catalog-sig] metadata In-Reply-To: Your message of "Thu, 06 Sep 2001 22:24:42 PDT." <20010907052442.35461.qmail@web11603.mail.yahoo.com> References: <20010907052442.35461.qmail@web11603.mail.yahoo.com> Message-ID: <200109071227.IAA06818@cj20424-a.reston1.va.home.com> I read lots of good things in Kapil's message. He doesn't seem to be the kind of guy who needs a PEP before he starts coding. That's fine. Sometimes you need to build a few prototypes before you can agree on a standard; actually the most successful standards are usually obtained that way. His alternative implementation can provide input for a revision of the PEP. I would hope that (a) the PEP is written in such a way to allow an implementation to collect more metadata than is standardized by the PEP; (b) Kapil makes his implementation conformant to the PEP by making his extensions optional (at least in some kind of compatibility mode); (c) the PEP authors and Kapil can keep talking so that Kapil won't have to learn on his own the wisdom collected in the PEP, and the PEP can benefit from Kapil's experience. (Actually, that's two PEPs: 241 and 243.) --Guido van Rossum (home page: http://www.python.org/~guido/) From s-thapa-11@alumni.uchicago.edu Mon Sep 10 21:53:20 2001 From: s-thapa-11@alumni.uchicago.edu (Suchandra Thapa) Date: Mon, 10 Sep 2001 15:53:20 -0500 Subject: [Catalog-sig] prototype Message-ID: <20010910155319.D971@hepcat> --QXO0/MSS4VvK6f+D Content-Type: multipart/mixed; boundary="sfyO1m2EN8ZOtJL6" Content-Disposition: inline --sfyO1m2EN8ZOtJL6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've attached a tarball with a prototype module installer. I did some checks on it and it should work in simple cases. Currently, the packages and servers file has dummy information that I've been using to test various features. Currently, there are two major assumptions in the code: 1. Any package is available on any of the servers 2. Package filenames correspond to the directory they untar to (e.g. spam-1.2.tar.gz creates a directory spam-1.2 after being untarred). --=20 ------------------------------------------------------------------ Suchandra S. Thapa=20 s-thapa-11@alumni.uchicago.edu ------------------------------------------------------------------ --sfyO1m2EN8ZOtJL6 Content-Type: application/x-gzip Content-Disposition: attachment; filename="ciphon.tar.gz" Content-Transfer-Encoding: base64 H4sIAOsfnTsAA+w8TXMbR3Y9AD+EEalvUZTWslsfXIAyCQGkLO7SojaOLO9q49Cx6ay8ohhm iBmQI4Iz0PRAJG2qJlltypWkklQOW5VUbrnkkBxzyjVVueQXpCr/YM/JOe+97p7pwQcp2Zaz SRmyoEF/vH79+n33Gze2vMZ2tb3PXuOnVq/VbtdqrAafhdu3cv/CZ27hnQVWW5i/dXthYb5+ C57r9dvz84zXXidS+tMRsRNxzkQYBp1Dxh3V/3/004zCHb6+3uzEnchbX+f+TjuMYh54Ivbc ddEI256wVaPYF7Z+bjuNbWfTa/kinuGNMGj6m7btek0eeSJsPfPe99pe4HpBw/dERQ1edna8 6UW7dPXq1R97MXc4zuZhkzutlgYoeLzl4Pqey+OQb3jcD+CEWi343QwjboACMLZdaoYhX+J1 u6TGtbc3BTRIlKoP9OTfU+Ar03ZJDTG2UN30YjXiQ/iJg1zaAI2D4ThAbim/GwLmB03E4Yvn iE2KIiDOFZDqtrcPK8PWS36TB2HMDWSr6QY1ZBpYir2dNkA9hJ7TOAxXBPC4Gs4wlkoXUyhW txyxDt0V+KsGaOxXoWkNt8DLwv/cKy+2wmCzoje+Ak00afq5PRhqDvkUsGo9ArieiwtEHrBi oMFLpkqpDwTYr/hBuxMrRvrAD1zuwN925AexIjiO4jg72nFiPwyIcxx9MMg3uImWFyhQ/MoS n0O8gcOrIna9KKruRn7sVa4+CJ45Ld/lHdHBM53l7ZbnCI8Lz+NbXqt9FQ7BawkPZxuMAdsl 0Kv1NeiIo32iSsZTR0kJjPb2Gl47J2jV5TD+IOwELgFTuIadWOOqOJhOp4njiAWd2NkAjB8H V4lfJHnxCfcLxAdsah/a/eCZ2C1yBcDgt17u1kyreoit+uM6JfhsacrlG/uxJwA0n+LIYjPE xKuSUdamCWNC8u2lXE9ffD8NQY44DljkedDYNm3TppGdlMT9buh2Wl6lEe7sAAeJGTpQxVdK cQiue1EbNdBYDuIxZEJC1WgkVtMQVsuKLGWUhhxL2yVcOj/gquaWVRCFAJhiDVGAabwTZDpR KxvXOCtCxWm3o3DPBzw8QgsIYZfsHv3fUPa/8RptzBH2/9bC7TrZ/4X67YW5+Tm0/9j9nf3/ Fj43fj1ub/73371L519gp5h4DA8J/Gcxl7FtxloWe2QxKykw12LbBfaowJIhei6yR0V6GGKP hlgywtwC+yVjj4ZZMsncIj2PsGSWuUP0PIqDVyrDsEDFgi8xDl85T2O5YbES/CkyMQcjAGQy ypISzntuscRmscX8AnvB2HNY8DiLh5g/TD+LLBljB0Xmj7IDxl7AeMBinG1BFwA5wfb+gx0M M/84DgY0oSX6N/YcgJ9kBwBknB2M4qyx8J9gq6dYfEI1PD/GktNs72fs4Jgx+zSL7rHn8HCG HYww/zQ7KMjZ0zD7LK46FJ8hdM6qLvivACS5A8Oh4U4AFH36N+xhck4DGM0AnO8CMNoNYFQC ICCPAMgEAlkBKkviivfh65vwsHw8JR85QwzhF6iR5co5fCrCF3heYgT+la6WOA2PPe6WOI4Q MmeHfhsmTZyA33nni5aisbbsU36XORWRE6PwW+lIelYeA81HkyQbFSKlDA/PFWfhVx8TTFPR zND+EAaCUA4OdaLrQo3ac0G4PZhp6mgo6Y66qTFoCybmGqcKngN9EWGqN7XqHrSbESauQk/R KhZK1kn4c8YqWWdYyTqHz/TvLPytWyB0I2wUhe4KCt0kSy6y5BKLmRIlkL4nRRZeANb8HosL zAe2HEI5eIFM+GtovowjgTsvoli+yfbPsuQtFo+gaElRfBjMs4QDU4MUldgTm4VXmAWf5AoB tAkgDbaSq8wdZitBgVmfJdeZO0KiP2WMG5Xjvs/2PiOhHiOxBEH9PovukyooY/sB4gMyWjGm lrAVBNC12cVmgU0QoGl2YOnGBVjs6b+ATN0wZh3HATQWMauM4RnMw9dXcD5Be8FkTrJyuGdJ wifehK9D/Tp7uUU8cRK+8g6bLSUXJSznbdmpMIvz8NDPa7IrJ7WUg5csholtwZ2lFnC8SO6l o0yd5ID1iMEgKTO5vlsfHIPf2s3Vq4CLl6GcSrcpXCQfNDpDNTcjJ9SHKJLBQjZuKiM848lU vKwJ60Jh3BqxzoI4nbXGQNzOkoCNW1es81ajAIa1iOJ1HU3rLEuqLLmpxAtk605SQ2E6IEG7 A1K0UiHcP8gU6td0Q3MU/yh7/oZcS3u5UtTmPEciOk2NOZ0DMnaFRKB/16Hkz7nts4zYA8k/ blWO6SlZKqPXu0i5t5vpDCs2iGd799aDUQWpbMLqnaMR6JnbB9luJAdgNphkqD9+ZMlm5Mrz hbEzYyjx5qfht7fC4PUmANH/Xxjs/8/funVb+f8L9bl3IBaoz9Xmat/5/9/G59qVmx0R3dzw g5te8Iy392Ngh7k04xeDYds083/qUTGv/qkSgPoXcqBM3Ow4flBRIfUnnuPOemD0eCsM29IL jaBNyFQJqRbXF20nBgCCo3FzOWg0HEiBdE/Ez6+uEPvyZ7XqHL8Xtvcjf3Mr5nO1Wp2vdBpb ADJy+KdbTtuR6YvepMEKmNuW3wAr51XjvZistfptqlA5fXfLb3m8Tok8wnmJl8v9chFlQYjd 5eVpY6wa5gdV3HfLD7xKrpuoXRXtlh/LzNTq4mx9bVqmDY101dISr1G6Rc9cLaP2pLSI31SZ p9oauglaxZpJGk1kSpOq3ISegyB0PssciAf5E1hDJY50j8IoO2wck0vQvQ8jW86+IJ+GqIvD eMYHeOwajT6pOdhrncMsdH4qOqeGO0N4alfT/XN3j4P3Wq1w18vg98tiGXDMvJoBZ0plkTAF OmCh+0HsRXKLq2qxNbnZMJLunFxYk7ZfQkwuQokgvU86e0ncpx3NFIgmzvf2oKUGtL9G4d2O NCQQ0AETGTGdDvTAZj/zXQ9c0WYnaJCv0JAjcpYIoMVbvsgGxc42xoy7IQgntTgROgI6baay ZnSMAMiLYsG9IMYxAApCz3jLQ0rs6EPgS3cz4EgiHKD70iX2CWActv0GTsA1Ym8vxs3CXhTG sBe5a/4E1Li+u/ClKsHNwbPIby9d2kZQdGCwWcdcGJRZDCyKVES2gN8R2N12GLjYBKsDVsCh z7wWQEj9MkJ3y/OjrvFyiUyR2NSwxL8o44mWF3n5Ppwjl/qiPMPLeKx9mknAF+U/z21z5deL f0qvdCTiLrHRAg/oyc3gd7oF/EGY4gH3PwTdLGgM4EVoZUghe3hOYwuAyIO21YTqoSlcW93+ HDGIHKXDx0j71Zs2/X/zUZR67f7f4PxvvT5/az69/4UO8v/q393/fiufl7r/1Y5dCHIBlmdG +4VkmEBk4HkFyJOz+z8BMWp5yjPsRKT7bgov7rR5hW5Ad0DYd8BSeO50f++u/CnZIc9B1FDL dU3j+178OCgr5wNjJIhmczhgOpH3BLSiyh8oJwmhejvteF8mSs0s6Qz3m3YpdaW2HNSyct8q AAdNirkan0ycxDBN8/BdP94iz9UuYYCdYVGV19ZpMnaJ972jzjtBd7XPqbeylG0muz7WXsO0 dgNVxxHXhVNkQtLR0g0xYaX+4FEwjJvtPnC6rknpcIx9yItJ8Ngq030dpJRMXNMp583B2aM3 ZwAfgDKgKlGDGTAZHaxXvRVULgtyduq5+AFaVmjPu7fE2uYdoJxGN3yZ5JgDkBOpW3G0vhs0 JpaX85JQ1mPSufTEs9v3jFfT6gTjyKuS/dUg8pt6hKaM27DtRssRAkItQ6qVvIctV+TFvfsm FIsqmqBswDeJ19crwms1yeUmwvqx77Qwb5UDMYNuKwgoeS5A3A44mLiLwGt4QoC3I+GWrnEZ +QXhrnRf3dATQTmGf/kOBIIzfAOkHZyLIO7AvvbloF0fQliaDOFYF+5Nv6XSXQDCgekBxEHg zoYo7Dg92BTIp7CJ6vo6oPXMi1CaV9ey1rYTgezHsgPLQ0pGMQAuoEoFQlGFaGoLPPo2LIh7 hABSQizLS/vGBxh4wsg2KAU9EzytqGyUCjz46H4UhZHke4lBA3YWe/K40nn5OgAZ8AZUryLX SaNTHRLl9pGLUnEUoLEk0YSDqaDWysZP8zt8TpWEKOCNVihk3AtNjg9htkSPcK+UdVo8hYEp AMJvSpQ5iC0+T6dYKQpqpOCftrE8aO5pFbGWiPfTGSAiksJliVz+HKtOGzNslUFg66o0wWv1 QFXyMhvvt71yWoaTm4uUrpSj9g769SBngetEblmX5PTwzmoe5hopTWOHNC3V0aXSAHJKsUcQ i6iuTapOyYnwyW9yRhJbnpVpCHqOMke+B4Hr7WFZSdax4+zpVmSQPLWn+Syv20o9QOjhxSvU 8Z7rwi+RUxSfYDepAjk51VztEK9glA5u+hG0yhFKQwzEUC67ediiqiQpgABUL0vkEzIvhQfc B/xd3rV5STpiebmWPCNJP4K6lIcjVnvBrvXfy9tLHIvgbC3YCk873Z0ymp/C+XcRlIZT/AV9 qOJSXglB7fktV8f2ZPooIQe6Ewxr7O0o4mYEyPgnLQzLs69k8xTJI3g9x3RyTiYx6eF16TmE OsNTbac2+p7YluYDFV5e1+P+7hEE0PS9ZkBzUI+Duhz2Ga2u6Da9wMNWMFwOcM4uEM6rkrva D5LMH4GZaTnBthRMoD7G0WqKC9MVw8okJPpa2Njfy1EAFVs5kqcXZTbSYLb++UjtfMpxMgUn dYvCom7nNM4A3SlnGxZvoBXbNazYgBzcPQetOf3QnhcCoNpTIHIH6Yw+d4hOfVytVnvq3fDY 1c79oEvOTKWmCPg4SMlEKpJn++nRfsor6nHkTc8od0e3QWj2+FikTfr7SDIx/6G/gZVhU+Jm y9+4KdumRBV+C0B6NoWD1XRIw3bkNf29mVS9yw+ng8d9AzLrVKZZW3uJQSqyMIIQcnZUtk/6 MagUXT+qpPhq/xxHUb5VDV9UjKZ9H1/gNNzalMQ/hTBDU6d1TWvqtCo+k72ZVjTxS5+VHsxi JakjzJpVIP69rriun6+McSEXIVfaKI46HkxudKIIEAHH0mntYrZbdkP46oCY8NRMGLXB3eia Oq7eR+/V1B7UUkfsAFFu9rIYtisAR2Kt1F7X8lmY1seKOPBfFDn7OvwFNYUX7LoCaQDHd1kD 49CU7VJ6Pb1H0mvRyKBBRisXkgCu99K95dPZeotSKQ+EUOX8Q7AHkV3CICQPQoCWAauI/Iy3 8dpwCNBBLe8QpEqUY5Wz1JYdeGh6gGiDFD5oLs7vVzerEEVue/np6QoxxYuocYh6ClJuLGgl mxLcN8wPv08aFgsCYEdRuBvwjf1Ua4FRJC12o/uTD/qkz5JCUmdCrRRGUX6krwkFh10IDcx0 gAzAaZzt+g2gqqpVQ0bSlWw60spV1VB6ZsPzQLvsbTkdzF1lK/5vp9h+oz9p/vc1FgAfkf9d mJtbMOp/6f6//s539b/fygfrf+/q+t8RrP/9V9a//reY1f/2Kf4dNop/S0bx7+Ws+DcpY2Ff k2FJH7S8YOznj46x5HMs6GtSAZ9uLbHkb7FWD+fZLPkHrMzzjrOmhaV4etAYS/6RuWPMG6OO 8bRjXJYZY93bIWXGFhVlicu422FVaRwz5lOBsUv1thZsaUWWNs3A16tktKnU6yXy17p0qquu Dive0ro6uYm0sM0o+MESoerNVIRJ1WVJxWFZtYsVUrDfYfgD+/1P3G8Ji6WTE7hfrJ0uYBV0 XDCqPYdY+AdUB31QwAJIWad28YWswj6NpWrhW9B/hsXDzB/Bomu3oEdRnWTwBnSfM7qL+e4V 6J4g6Md0NfcFY7SqBJ1kezewhtSlivLoMtV2XjTGjWA5J0F8+s/sIfDRiqwE+xV8/UYm/2VR 5yTLijq7su+2eKOnM5dWt6los18y3M4qtWEecBayx4CybKSS3myfMs98tfRhzElDU5/QLFqj Wm6circywzkW7oLfgwzWRndBOoTrsexO5cpLkrbFYrEwZk3AH9t6q/BW4SRWZbKSUYl5F8Xg MtYqJ9ysxLyi5ADY+Q4WIhd1WWZyDbkSf0APVQETNeYy6r7CpYBZJDiksKcC3q68vvhYdX6j mfxlWV6aVxb5ekyDpK9Yttl9OD2VjpflyliVPm7hHxqS817JFqF+Fj/FYyqjIXrEsJA7uYGH gWYB9NCyNjmgv1a0yQEF8VibHFAqLuoOaZY+UUf2Fqrywy8rqCB+BPnk37Eg/gZL3saK3U3i k3VYuoZvaOAzLD3H9qF3nsVUFe8PK+OBKu0Wi0dJfxXYiwLqzofBLEveYUOxrIF/U9bA30ZQ vq2q5a1kATejCuB/wPa4BWyn3j0BoD9gEbNQZ/+QxePMP0GV68O0AKjJRRafwuJ3VOQj7Alj 4XWA+C5yrn8aQVjJHRafQZt7IOvff2ExfJEkWSJwZ3EyLEPKHoj5I9SwYJqfFCSk3yJcAdh5 Y3iJhpNi34Ax79Ecm+Z8DL9/Ww8C6w0Gu1lgT0ZYOAk99/RqCJQK8O+Q5bhPKI7reYCpLtan d17+kj1MHphb+ikJJ5zHBEt+hyhASCIRSmwSOy4QTckpED8kof2KF04kGyoIoRLbaFnqXXxe kuX9b7CsvL/fPYbUpARDGoSxTNlR4pO0YNTeIXHT+U5xLQd2YD6/MqnNAAbU4gI8rOfkK017 iUt9+rJkrMDNhFLMMUdDgpvdURFyOotHgzCvR3uTGTIilbqUIpp0L2VmbZUhURdPSi0GnjI6 aHnJftC1EyFi4GkaMMrKkRoywko5FW9xaJn0xoagyzyS+N5AOlGGnQxLd7/O7EvNkpLcIEG6 j/y6OdLld3OIMsVZOjV4Qxof0KNDY9ZYYcQ6D+butHXKGqNXD/DXuHXBmiicsq5D6yVrsnBt aBx6M993ArXrMks+YsnHqLWkcsucXoT/6vctJA3L0lqkFDmCuNLF1aMPocAZYpLuG6Ll1NMt NCxt4uk9xhWWfMqS31f6QGoZ9G5PgdL4GapsUB9aAT6k/iE19iK6up/hjyGfXICFAmr+R6h2 VjIaXUrdn37XQyTdy13c8XUYjQhi5E4Ole5My3SdhtExmNSnmHzLzST0ilRV8p2XU/iWSyFj J1SrYHyTNZasayuhQ6nwDBD4D1UrhgErwTFo2SBuy155uUsc93UupHpVqalCVbSVEuII/We8 /ffSHJp/oRGv2x5Lrwm5cwIJVtCxWBmdC5clHks2e2LPZMtokq/aJT4aMbTKT9jeNn6DnR0L 16Fn2xisvIgWNaUvyILDsEPuCMEChwGt8ziMC/AHAA3OwY82HVGJvBG56NN3mfUwecr2wbRG LKZX4cCzQHdjCPyZ6ywR6MUkMS13gjBQL+h10HFYAdn6LHlGkRyBhi3Az+gSobRLb98W6MU8 ZeGf/hdY9z1qP0nWHYFUUEeKRfj66td4pM9e+crOJnkdfD+noq6JdFD3nZu08Pi1Sxi88k2W vUxMbRv3URUUzsPjMmRVvK5Tps/1pYufWthMB6Tm86VcBsNipiY/Z80M49f1lqC8MBvOSWDP VLVOin4G7gihy7sTLiNDikJ3FvRUyRphx1FfoVksTFoj8C++r3fcOgnGctKSKnqUwLhhA7Zr 2toBZqeviuyjAI70fbKdDQ6ictPLUg+XYHdj18eGx0pjx/oH+lkoRRHv5zqU+oIlB0Yo9aUR Sv2VEUr9KgulPlHvlt9gOnx6mRtNSjxRJPX3uP4BS57jslJZxUwpt4vqqcguNotsAhXDH2G0 hSb4j1W6R6ojjKp+wfZ+rKIqeI4WSSO+oGGkuDAUKKBqVDFDiIrtl0wGUdCchhEfg6L5E3r3 F45nHEkj97hM7+cedclKcu+nuTm6uJTxhSmX8gaWTsu8S5XuoL7h7MqHKLdbB+EuOFf4rC5O aTW69Mwcc8qs4AVqt3iSjGGOc72HNYyLti6ZzGOTxzRb3EDpJV3WA0YSU7TKxRJIImZkOMge ZWXIg7iJPPIlS/6UJX+mzsWXweJxOMI/p7wu+Q1/0eU3/BwF5HVd3mb/FwTlPnS/nf+SRM77 YAaQQ8iXO4ovlSNRKKLmKhDdLKQbij7IbfLX7H/au7bmNo7sPCApkoBA0bpRpmWvR/IFZAyC AEiQFiXbWVm0bEdWZFKSN6aYFEiMSKxBAMJFIhVpkZTLqWyqdre8KSflXCp526Q2W/kXeUnl Oc95yHP+Qs6lu6e7MUOQkkjbpWkWSWCmu+f06dOXOX3Odzp/TUzy96fXdM48g0NhwQei+Eka hLnEE34ldu19/byJpKYgugRMO52/cTp/K7aLy6TOp4e97aj94b6Pmu1Xkt4dttctn6EC/cbX uvOwCl1UzGGmMcassNfiEDjvP2QtGywQseTR5HByUCwEksPfOp1/cjr/LE4ANA4nYjqHn/cD 9uv+AZJ5vt6jT7ADld3Ct0IiBvtjtl7CX55pCP9GLs//4nT+FVdcejouRr3O1zmnJmq9KLQI +Q3TiPJiv2JaNP5W0vhvTud3isb3SQif+tD+iZqh0fpbvxm8FPeEBBBrrbmVJm2TpR/XVeLB 7vuGhIScuxiCQd98mwxbZ2W1jWFHBL3dz9Pp28uz7afp2Ai6gmEvUAWhXNul5yQ6AW6tT/b9 qC85kDyVTIwtj72aPDaOnRilw0jv316ePuhnZLOzu+E/YGL7j3xufiZfQHuRuVzBcQsHTRim 59z+A/t/qVZrHeQzeuD/ZbN59P/MQ//PZXNzhP87W5iL7H8OIxH6R6W2XqxMr99vNkASInu5 5ynR+PfqtWa5VWsckBN4z/GfnbfGf34+F9n/HUpi/KdozD+vCcf/ImvxDuwZvcb/XHbe2v/l c4UI/+FQ0vS1j95fvL68OJ3L0M/0Z17J/cBbc/Nvu/nswkx+YSZHeFrT04lpBRYHufPTy+2q u+zVXfeCm59ZyM4uFAp+TgFCBxln7IxvL+Rn/IzyhTAo5/zCbF7llMgvIusnNc6ay7q5CwuF CwuzfqU6ZnpA9rmFArRs3s7epFbpGYHS7EL+gsoo1BgB+XKFhYJf4dLij698spi5snh78dof 3lhcsgtArbn8QkERfOW7m399rh7cM3qM//nCjD/+C3M0/vP5aPwfStob/strwrpCgox1AcK0 G5VKeS3t3m3V4T/kp1cKOzsPduW0huMzYflONnT0GHVyw4pO3xIkxFNS1az8fiUMAp+zq7Ag mk+ZjtagIFn0CcSKCxLkZrhbsBGrdr9ypNG/LQ4HfQ9wZa8OtN7mm3aECJFTA5KwnvWWm5pK wV/rGXA5A0Kf2XiYMv0ifZc+RHKwG6ohzZjPIfA3DXTCL6H7Kmr5J0OcltncXRS6U2WvW6Ok 5g9pomkAl5a8ZrvS8rkAlyYsv2J2vhfdc9VrCZCEK7UH1UqNdeviSSkKFyFrFzW2q3g3uFLR +aLGW5SzV31kzGRXx1jSDPC3TofF7JRt0H4ZS4pn0WfzUQZryAmuq3d2ZY3ZGPEt4BHSuVqO RWS57hZ6k89iSoK/RgQWhQMEM0UrVPTlXVuE0Ku4VX9fQgq655cWby6550G27WqV+MtxkmDs FeHOI7zRrTzCKZ0c75l2GuhZja26G77MIv3hTTAHf9IxISYYVwOasSwL8PSZ+eDmDXFTPkzL loHqqt56S3OwVwgwzdr6F14r4ykYGClO5/mOS3coFIhRZaW2Ua5OpIrVWnVnq9ZuIjBJC5aA 379bq8HztlLh1IAINNbKCDw44XcIoy8wh3lwcwUmN3M66Tp4TdhAtRimeeCLSgSntfOLXYa9 wBSwhdOlJbFY3RGnVufOSwgZszsDgEomu92l1aShDwueHbSTsGaNz8zK0IRiFWMy4NTQ0u0c 2aNVPeA2rK7kcM8L80QKdzHb9x/eVWgFhjwLSDCtrISQVfgIvr95yEQj+NWu4qME5cgc2VCe zfR2XmZjTdXMNp6vIsZvq90qV5qiQXXkZLV1pdzgFsE4WX/A0yJ8W99EXIAUmdekCBdAZU/b rVxZmJpnZB4Dk8QffzoICuFaEAqPxocutgpAZJf8/GCX7K4h+X+CxQxotD0XR5akpEQFd4lq td/UyeCuCs25exeyEa3WhT6QStdOQEM9C+hI1Y/PqhurWjc+s06E++7UrfubMDYymDdwX7Hv rhSsSklCD74njWVZ9KU0gzZ70wffDsBk9EEouGjDu9eGyZ77UczxctZpaACFDRNhUF7NaDsK OZlrhKbd7UB45hTbNJS7NhfoznKnerV8H68BqxHLBbtse/JioldUtO6nXK+5zfb6pmq0t43O ducQVuciYk49CfSfZNwesP90ZD8pMKsCT1ui9unXz8u6lcff+WeN42BIkQ3ksNyuew3OR8Ya QInnP63hVdg+2sdg5k0W7SuaXSgPQXKrfzHQIzRJMGP1BdSozWkB9blc4ZrcGPesTu0JQokr aa8I8JVQAB/g0KytSbDloKd816/3PZOv/zk4AIge+A8Fif87n88V5uZmUP8zUyhE+p/DSIj/ 8O9n/5HxH4YQ/+F/nWD8h4Hd8B/wwxECfxikz4MI/oAfhgj5YRjtde86wrJcIj/sSOvyuNP5 SjrqJhy07h2UeA9DOt7D1+hQIvAe4hreA9qpJ+QNHyHiGMFIBCBEjPZGiCBrKTWl+jZwt5E7 w9IGLo4x6Xwz+hOaGX1WM6O/pnkk3/I9kjsbAgoDeLW0zOFjXEcCTYQrv3yD6Q5Sk6BIeOzw yl7JFAxPxcbDK4MYDA/zDMkrwwgAIWzfExQGzyFUBXLw+ZKvA8tfEL7J0Mgz+CnpnIE2ntEs 5tFw7DqZc02REZpQLbH9nebobpqfKTNctP9SZrgNuc/rin6D3zVNHFmx6sUUfkCw7dtpK7tv dxsUtCqoYhGMTqjiurIJ3VoXXfLVxDI+tp6q2cmhlV9GO+wwbIYT0v/uBP0k0XpeOTyiKIMI dk76znf4gRweaiedmLg6oF19g6IN+ngaMXGP46KNUQdXGYkDY7qN021G7EBndgoTh85fZ51W QnipsTflTzqvODvHEV8BS5Dveozyv0r5XaeVxPGh5T9P+V+j/CMif8rpvE753yAaj+Hlqx92 3nRao8LNTZaecHZgmplkmt6iMmn0Ay8d0XNlqEEktYMktSI2mmb/Th0boA8kuerS6pE/g61/ I5Hu1plNHDckIFwiu0MVBsmjbi++qyPYqFUBCLEci6wxpRzWRqhrWLIWg6RP3yMRW/R8tOci mZXaS8rStW2jdgVtD81xYhC62ygZ8pl2gp2U+mPTfS/Fjvahmxf8wv/j2v9j9GkI76L3wRB7 ZD7EIZR1OjmEdegeRRhKdIZGySDPhkecM+isxDgP9F1BPXTmyFkTZvx5Z+d/ELZh+7/x76MB J1n7TxhSF8TMyqNDYDeMCClHl6aLzs4pp3OJooBKTAcYFOeczjvOQOu4Uz5BIBKjDCLxLo6I qx8yasR7InQoiD/7aiJww85rDkMzlE+RgxSBONC9y7jOkjvneafzPlQ+RjWf5JqvOK0z0k+a al+kSl6kQXrvDtD0WXXC6XwA5cad8ktUdIyLXsWisGaLMUilP5LtPquwG/phUMalkyc6H4bo jUmqSdHL/pTseomLt67eTJDUKF0myYquzGSfrZQjXTF7KgCvT7xsCGXo2nOUpVWqnkPH7qg/ +6u8YQsHLTy+ZtV3uqTrSstKX33tatiyGuixqLldDvLDKuU1mlQ+uHmDmKlUrjztsAKayxHj 2S1MIS2QOpko8rXD2oykw0IEzT0+jIO2fbDt0oNdMnkTpXoqgEcaK82WWQzUmBLQXbtNRUdo wQYuZxVEA6zTp2Kn++Iw8aAf6onYKHw6BT8jNDkhVMNx+BnDa30vaGv6J7jBu+Z0PkGUhpb0 nvcXaZxobghYInToRj+5Txk+BiEOlnHdVCsl+cuRT9KcWsz2q4SmftB0zewPRtIbpB5mv1rh tDDIyxR66YeOJSX2vg/U7WIleA0JWCtUid47Kl7RrvlwROOxF9CrDp2kaDH4D+T9LadzG3Eg 1P4a5/s/oq/0+vOoz5/4j7oqpOyK3E7TfhsYj50Dk2LnDhUdFp0C3VeFWbbzx/LqEXEVsRIY wQfKnYUcRfFI4ZWPyAlD0MkufCxZtzzajMlJl0DRKErxq3KvEq6R9z1ZyzSQJAwN4iSEa8LJ +T1Y090lHqbqmSHKNPFgpTEjoihFKE8IqB3dg9yETHwBXtmaOO5F2EzkCLOESW+vfYrYJd1i 1AAUvdHYeRC/sb4TMPhRCGkKEGL4XyiGG05n0+mUTTH8aU8xrASJ4StwY8sXQ0ZlGNOksdYl jfcsaWxYItf0pbFt3bqPmBEB0ug6PnJa2MFCmDiO8n9dp0+oKWEqeiGFY0oKbaW54Vv11HJY fWI5DNswmNIWtnV+NhIad/h9ky5sKBmNsYy+oskoL7ah/q3aljzwJSTkFSP4jcLmjDxzUA3Z pTWq2DBHwyav2OHkj5IvJ+PJE/5I+yWOtB1ESej8qbPzOsIVKGhACX75mPbN/eIF9XOn8zPY 9g7QnhekH3HZYp0Ohj4HiS2T2kvimlSn4NafEfYb7H6xwEu8Sf5zLbtAJ8CNMgxNsVoTYt3u Rze8p8XXnt1OVRL6oUqChkzI8YhEjzTYFwLg2DB6uusNESnb3nPg8K4g4CzVYU+mynfrfxwO eNayI7EH+gn34zj8noXdlhWb+yun8xdO5y91RMifB8bmnnFM3Mc9nggZnDruf/ZPezSEIiz6 NBG0u3jR5cr5lYqh3TcS6+o5y/H3F1Lp+UvEGpCOv+/An6c6M+rp8tvVDJvOX2i+yyFTo9WU r2VTfo2ACbIpLwWNHrU07Z/OEFq+1sgN3GlYxH4jiSVIBEnsOPwJPebaP62BhHyjURrwnmbR +a2k8++czt8rOvOKqfs5Qdt/AwLo+1ZzBie8pCdxBmfDVv292Hon1ectc7ZUY7jbhdp0/O6a MkMkJ0STFtD0LuW7oiWsapN0wYjg5wWwZy9O4l2ttLmn8TioSbt0vuFL3p/qO903di+ZTA6P D+CPE6XwZLpKHMwzetj/z2VnZhX+f2EG7f9n8FJ0/nsI6ent/xuejAdLvgC72/4nLMMLEadz lyhJxfvFcqW45u99gZw4IetzRfCh3eQI5/BSEVCBMuvHfW4iXmy6JQ/xsbzqetlrZvYRmJKe d7/YKCM5SEZ8ySsC0f6m3H8265AZXVCEWVeEiFDbVTImxshJCKdabCDUVIthBVuN4nrLp3NH rzrjuhxYAKoms7vaGtCzI0FzKgiqI0FweGkNJRCKF91qrTrFPdZQfsBuEW2JtzxGec2wgR/Z TXsVigC+ksKXXDQTFgef+LEilKMU1hA4hv+LbXglb3Bcc2hVSo+O+cWGiAFLoTERlfAGceEd oAQV9XUEtmmkJjK/995keve/7p0V+DB5Z5WDpRHjdqnM1f/Z9vI9AnPKbmQjTmjEfkNzCnt8 Pe6mqCUg8KZ0GiEWxaHv4F3tHVfxKtP0io31zQkzKKYM1UnZMxuNWrsurM2ZM00zhOTcakDJ +kSluLVWKrrbC2Z0ze3JtFaYar1Le2YMQ4gxRItV2MAVRLgu0YIVlpwVyrVqhbAsy7iGGnlG lFFxGZh6UZnOxl+jPHUXx3jzXrvY8Nw1GDZ4GqFU2bogNLwNIBA12w9qjS/MpwU2F4ZDpbju TWzDc1dRglPQclFmcp/lV7rK+xXwRKT6+DUxFxg3KcIxs1IynO8jx0WdzHApIlrTpZDwJTai L99l6XDPveNel2EESQhawZID48PbqiOVPPQXKCsGjnNTW+Xq7WJDXsrRpeL2bU9dyq8+Fvb/ WqNWZA0oDli5JvErKT0nWUbqFzR3FjGLrBghUVd9Nys/Aqb0ogr2FDNDYYqTdVe6TBnAVXbQ T0GCCnhpVy0510WxyrbqGwUTJ1bUtGpGwCRjYKUZmfTbZrjJ9GqcnKcJK+8wG6UWiD226goL ds9GdQ2VQ22VKal7a9kyLI89m4Vr6KH3ES3cu7cinjBjyrJr5G7B+bSMT4QcqJXPxJ8BbKBO z75BA7XCITH5VFA+g0HPPCCf6hLbiNtC4vOPV0QwIYa7LvNsIO+Viq3iWrGpWS9/1+8mUTr4 ZL7/H4wNeA/779xcXnv/L6D990weskfv/4eQ0P579f/+ge2/B9D++yvnWdl/YyBA2+x7CENo CGvoYbKAPuJ4cbLP9qMCJtg+G/W/ofbZlkGwFTMqLpXRI2ja7FtoL2gW2pc1C+2PNQvtpe6Y UdtOOOj5QSso1mPQK8N4RDXX52BrOqcxWF6JbH6gBaUBYea3MUhWhC9qsanGRVQqjsiANgMv ySvD0qDxZYpf9QqaMJaHKUBDnG4dQ+tdjPdwDI3rZbwHMuEdaI3QAWaCDzBdYdl3ztn+OoZx G8iEsXTUgSuNn8Uew4fzSNTjITLw7cOwTY+OStuC1+lE9SQZNYBEvOE8Gkaj/fHH0HVvOq0x YbgPV5GGYYwHtp0hu8JjFMniKF5pnHUeJzBCGGR7lHDGHw2hwSR+unTvVOyzzqTDtomPRpzS KFUEtaep9heo9hF5cYouHjcvThP5STQM3f45VXIUPzceOY/jZCo6SG2KyzbNYJtarzg/7Xdq N2HszGpt7McIYFDdAAbJOuqM9+HJIn05gV9Oii+n8Mtp59LjUTQlfTTqPEo6osQlQq//K2jW PF0dckpjziW0LR0SkOnIQsx473fOZ6UzMJQoJNSRmBn36rnVZ9FxCFlp4BQjTffxPFW+obAZ BXCJAfVJicVGjtiW5hTOTPtRS9G5S4DuyYx9SOHEOK4And2o0Dp4fIWDQUYx+hKnR44tRKcx dpAsinTFZ+Mq+oh+TI71ZSyYJCLlEmsx3n3TITiw8hFZ+iIRM6DCRqV9Yngm+rLf8AVZpfJd 1CG/hV7kqehLM30WUVM9iFo5WKKmBNNisn7Wi3BMOPpOShE6v9Kn+OsTrszBajLLS0Bb5tRL HB3RNYQbAGs36QxPaQZpgdSUQE8WzI1A/Vk5aZjthgRr0yMjsAEtKp5IJkmjxLZVpFWyY7gN KXL5AHarWKdypE4U9h8YACswHpzNUcolakPirstAOKRyokv4tsvHworZPpkmJ/2COju07rJZ rbPBaqZGmN8mxb+uduhc6eohasIe5FMebIw6zcsOAdH3ncUwcbETKmzcMAWNi5Nl8ghcw2/j sdP9p9FquQ8jdZyIvQD3snB1BK1m+nli+gMcdgvoq4COCsphgmN+vUpRJUXoNYyoBvuPdylc JQUAGyGvhNYR4Vvgx6zA5uxVF6fP4HagtfDBowX26nIAk5wNsEIKc9/ac2+YTmQLyvaYoqmN 9ll8vYzOGJ0rgXxdtPj6gcnXD4P46pp8DVQDGqvg95+hlsfF5R4c/RjDg3auBXL0E4uj102O 3gji6Dmfo+E6yID5/vvOViGnQv/6cQ+uLok4i0FcvWVx9bbJ1Z8EcfVFn6tdKlC1Mfv+M3GI mYiq3iWbgz3ijVnOprZfkdk9+oNsO6nQQaNxKi6CiQ309yXfSg7jjxUt5nP0R+isdUeLiYVG i3mONL4iSIzF1T31hGkNjsU+V8Fi+gyZtIztNqR+g7wCdGPMp9L99rS7C91jSDo3NKM7siDe q9Gd2M9q2zvdzkwzuNOYFcA/y7TOGNbkd6DVFlBaC68SGuJEr7OLItEMQXsvzknDNWQSGq4l +8c+TeLDDy3JafUgn9EL/7mQzQv8j2w+V0D7r9xcIR/pfw8jPdi+QU4zaTefyWcKaXe63l6b vlurpV03N1O48Pbs27Npd6m2BjPGlXYV8qXdldVEtb1V30m7uXkolPUL5aehnnxutlDIYUbK SnXlMlmVD31x4Uo2K7KsrBUbnGOW/+Wyqxfh4sO0S5dWVxN6DlUHPsuvpFlveOubHhFIJah4 wcw/o/KvJvwC+cyMQdqsluvGztWGt/zpNSibyYtcOvGrP/BTMhuq+iCe0WP85ws5Lf5PlvCf Z+Zy0fg/jAQLmXhfKXn3vQqsdY3mQiKBOlncCdXdCl4Wxpyw9UEAeDKgauJRNdt2oum+sPZU umBSEsONRNHfrQm9sWEozoplr7i+KarIWPdbsAGDvcyDWgL2NVhNkVTM0vGFHoiOL/RB7AeL pZKLu32xBWo2a+tlGRWa/XMSFDVSow23j+SKKKtDlpD2gUvAfnDZU34+6FtI73hVN+FtF7fq QHcCuSYD3WE1Sj++GXJytFUmXZqZOQG7h7oHRAHbdzJ+jbBnaeIGg9+G4GqZg12SCSG1hpiI XxMYSVq4VGATKF6rq1BpV/gT6r9X4QEWmVrdCdJJWZW7WuWG/p1eecXOW9RJqn0vwZmQWNq9 66XgK3Atoaioku2k0Oek3VIZ5mhU4KfpTTDtsiY+jTtZb7pdpYM1UsIpy7pE4sEmbOTlV3wC PRiDfDe2YKEQT0q7qJ31oC7Wyq6m3UwmAwzhywnsFL4jveHhla+1w97wd43dM8YxrNZMDQCd h0gahFhCHejv1oLRASVW4Fk4+haQbVCV527BXISZhJ8mfGw98KAaJYb0cFFpxhWjtMktK4Jo oA0kqm1JmjdRcYodAjV/lNqizT+8IFXwJaxWA6LrdQ6eivVvuY3yxmYLMj2ATkskbtZKNZgG ptzLXgvPX8hXC8pUSzSo/RvwltDeAmJFd/JrRbPWbqwjzSUPs35UXa81YKLAIUhuP9DCWqu2 Xqs03Yk6bLfLeN4Db9abMvY5sOQhNMTFd5KSkNz3JrGuH1cqtQcoBjWUoHW3XS+xdxl0Mo8n fTgZsqZRjZRNq5cfr1neQNrXK23pR8VEodFoiW4KEQK6NxrFrRRJLaq2yy2QT3iz+cHuAsT0 cqDP6B3/bVbu/3Ps/5HDMBDR+n8ISa0KdGS6WYMZ6Acry1GKUpSiFKUoRSlKUYpSlKIUpShF KUpRilKUohSlKEUpSlGKUpSiFKUoRSlKUYpSlKIUpSg9L+n/AUJ5770A8AAA --sfyO1m2EN8ZOtJL6-- --QXO0/MSS4VvK6f+D Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjudKD8ACgkQ6nShCjt5AZIzfgCfXbgMwKcTIv0pMVqAEh9LUoYz RUgAniESd8YKVA5fGX/Xp/wlgnEVGcwv =hKAc -----END PGP SIGNATURE----- --QXO0/MSS4VvK6f+D-- From k_vertigo@yahoo.com Tue Sep 11 20:04:41 2001 From: k_vertigo@yahoo.com (Kapil Thangavelu) Date: Tue, 11 Sep 2001 12:04:41 -0700 (PDT) Subject: [Catalog-sig] metadata schema Message-ID: <20010911190441.53237.qmail@web11604.mail.yahoo.com> --0-375289087-1000235081=:52800 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline attached is a xml schema for metadata. based loosely off osd, xsa and debian's control files. i stayed away from using namespaces for simplicity. i've run it through the alphaworks schema quality checker, so it should be syntatically correct. overall, the format seems a bit verbose. i'm bit unclear about how best to trim the format, or if client requested info will result in a trimmed data set. i hope all subscribed are well, kapil __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com --0-375289087-1000235081=:52800 Content-Type: application/octet-stream; name="package-spec.xsd" Content-Transfer-Encoding: base64 Content-Description: package-spec.xsd Content-Disposition: attachment; filename="package-spec.xsd" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPHhzZDpz Y2hlbWEgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNj aGVtYSI+Cgo8IS0tIGRlZmluaXRpb24gb2Ygc2ltcGxlIHR5cGVzIC0tPgoK PHhzZDpzaW1wbGVUeXBlIG5hbWU9InBhY2thZ2VOYW1lVHlwZSI+CiAgICA8 eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpzdHJpbmciIC8+CjwveHNkOnNp bXBsZVR5cGU+Cgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0icGFja2FnZUhvbWVV UkxUeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmlu ZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlwZSBuYW1l PSJzdW1tYXJ5VHlwZSI+CiAgICA8eHNkOnJlc3RyaWN0aW9uIGJhc2U9Inhz ZDpzdHJpbmciIC8+CjwveHNkOnNpbXBsZVR5cGU+Cgo8eHNkOnNpbXBsZVR5 cGUgbmFtZT0iZGVzY3JpcHRpb25UeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rp b24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4 c2Q6c2ltcGxlVHlwZSBuYW1lPSJjYXRlZ29yeVR5cGUiPgogICAgPHhzZDpy ZXN0cmljdGlvbiBiYXNlPSJ4c2Q6c3RyaW5nIiAvPiAgCjwveHNkOnNpbXBs ZVR5cGU+Cgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0icGFja2FnZVZlcnNpb25U eXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyIg Lz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlwZSBuYW1lPSJy ZWxlYXNlRGF0ZVR5cGUiPgogICAgPHhzZDpyZXN0cmljdGlvbiBiYXNlPSJ4 c2Q6ZGF0ZSIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4c2Q6c2ltcGxlVHlw ZSBuYW1lPSJwbGF0Zm9ybU5hbWVUeXBlIj4KICAgIDx4c2Q6cmVzdHJpY3Rp b24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2ltcGxlVHlwZT4KCjx4 c2Q6c2ltcGxlVHlwZSBuYW1lPSJwbGF0Zm9ybUFyY2hUeXBlIj4KICAgIDx4 c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOnN0cmluZyIgLz4KPC94c2Q6c2lt cGxlVHlwZT4KCgo8eHNkOnNpbXBsZVR5cGUgbmFtZT0iZGVwZW5kZW5jeUtp bmRzIj4KICAgIDx4c2Q6cmVzdHJpY3Rpb24gYmFzZT0ieHNkOk5NVE9LRU4i PgogICAgICAgIDx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9IlJFUVVJUkVTIiAv PgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iU1VHR0VTVFMiIC8+Cgk8eHNk OmVudW1lcmF0aW9uIHZhbHVlPSJSRUNPTU1FTkRTIiAvPgoJPHhzZDplbnVt ZXJhdGlvbiB2YWx1ZT0iQ09ORkxJQ1RTIiAvPgoJPHhzZDplbnVtZXJhdGlv biB2YWx1ZT0iUkVQTEFDRVMiIC8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVl PSJFWFRFUk5BTCIgLz4KICAgIDwveHNkOnJlc3RyaWN0aW9uPgo8L3hzZDpz aW1wbGVUeXBlPgoKPHhzZDpzaW1wbGVUeXBlIG5hbWU9ImxpY2Vuc2VLaW5k cyI+CiAgICA8eHNkOnJlc3RyaWN0aW9uIGJhc2U9InhzZDpOTVRPS0VOIj4K ICAgICAgICA8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJHUEwiIC8+Cgk8eHNk OmVudW1lcmF0aW9uIHZhbHVlPSJMUEdMIiAvPgoJPHhzZDplbnVtZXJhdGlv biB2YWx1ZT0iQlNEIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iREZT RyIgLz4KCTx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Ik1JVCIgLz4KCTx4c2Q6 ZW51bWVyYXRpb24gdmFsdWU9IkFydGlzdGljIiAvPgoJPHhzZDplbnVtZXJh dGlvbiB2YWx1ZT0iTW96aWxsYVBMIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2 YWx1ZT0icHVibGljZG9tYWluIi8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVl PSJQeXRob24iIC8+Cgk8eHNkOmVudW1lcmF0aW9uIHZhbHVlPSJRVFBMIiAv PgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0iWm9wZVBMIiAvPgoJPHhzZDpl bnVtZXJhdGlvbiB2YWx1ZT0idW5rbm93biIgLz4KCTx4c2Q6ZW51bWVyYXRp b24gdmFsdWU9Im5vY29tbWVyaWNhbCIgLz4KCTx4c2Q6ZW51bWVyYXRpb24g dmFsdWU9Im5vc2VsbCIgLz4KCTx4c2Q6ZW51bWVyYXRpb24gdmFsdWU9Im5v c291cmNlIiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0ic2hhcmV3YXJl IiAvPgoJPHhzZDplbnVtZXJhdGlvbiB2YWx1ZT0ib3RoZXIiIC8+CiAgICAg PC94c2Q6cmVzdHJpY3Rpb24+CjwveHNkOnNpbXBsZVR5cGU+CgoKPHhzZDph dHRyaWJ1dGVHcm91cCBuYW1lPSJwYWNrYWdlUmVmR3JvdXAiPgogICAgPHhz ZDphdHRyaWJ1dGUgbmFtZT0ia2V5IiB0eXBlPSJ4c2Q6c3RyaW5nIiB1c2U9 InJlcXVpcmVkIi8+CiAgICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ2ZXJzaW9u IiB0eXBlPSJ4c2Q6c3RyaW5nIiAgdXNlPSJyZXF1aXJlZCIvPgo8L3hzZDph dHRyaWJ1dGVHcm91cD4KCjwhLS0gZGVmaW5pdGlvbiBvZiBjb21wbGV4IHR5 cGVzLS0+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImF1dGhvclR5cGUiPgog ICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6c3RyaW5n IiB1c2U9InJlcXVpcmVkIi8+CiAgIDx4c2Q6YXR0cmlidXRlIG5hbWU9InVy bCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJyZXF1aXJlZCIgLz4KPC94c2Q6 Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9InZlbmRvclR5 cGUiPgogICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJ4c2Q6 c3RyaW5nIiB1c2U9InJlcXVpcmVkIi8+CiAgIDx4c2Q6YXR0cmlidXRlIG5h bWU9InVybCIgdHlwZT0ieHNkOnN0cmluZyIgdXNlPSJyZXF1aXJlZCIgLz4K PC94c2Q6Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImNh dGVnb3JpZXNUeXBlIj4KICAgIDx4c2Q6c2VxdWVuY2U+CiAgICAgIDx4c2Q6 ZWxlbWVudCBuYW1lPSJjYXRlZ29yeSIgdHlwZT0iY2F0ZWdvcnlUeXBlIgog ICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0idW5ib3VuZGVkIiAv PgogICAgPC94c2Q6c2VxdWVuY2U+CjwveHNkOmNvbXBsZXhUeXBlPgoKPHhz ZDpjb21wbGV4VHlwZSBuYW1lPSJwYWNrYWdlS2V5VHlwZSI+CiAgPHhzZDph dHRyaWJ1dGVHcm91cCByZWY9InBhY2thZ2VSZWZHcm91cCIgLz4KPC94c2Q6 Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhUeXBlIG5hbWU9ImRlcGVkZW5j eVR5cGUiPgogIDx4c2Q6YXR0cmlidXRlIG5hbWU9InR5cGUiIHR5cGU9ImRl cGVuZGVuY3lLaW5kcyIgdXNlPSJyZXF1aXJlZCIvPgogIDx4c2Q6YXR0cmli dXRlR3JvdXAgcmVmPSJwYWNrYWdlUmVmR3JvdXAiIC8+CjwveHNkOmNvbXBs ZXhUeXBlPgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJsaWNlbnNlVHlwZSI+ CiAgPHhzZDphdHRyaWJ1dGUgbmFtZT0idHlwZSIgdHlwZT0ibGljZW5zZUtp bmRzIiB1c2U9InJlcXVpcmVkIiAvPgogIDx4c2Q6YXR0cmlidXRlIG5hbWU9 InZlcnNpb24iIHR5cGU9InhzZDpzdHJpbmciIHVzZT0ib3B0aW9uYWwiIC8+ CjwveHNkOmNvbXBsZXhUeXBlPgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJw cm92aWRlc1R5cGUiPgogICAgPHhzZDpzZXF1ZW5jZT4KICAgICAgIDx4c2Q6 ZWxlbWVudCBuYW1lPSJwYWNrYWdlX2tleSIgdHlwZT0icGFja2FnZUtleVR5 cGUiIAogICAgICAgICAgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9InVuYm91 bmRlZCIvPgogICAgPC94c2Q6c2VxdWVuY2U+CjwveHNkOmNvbXBsZXhUeXBl PgoKPHhzZDpjb21wbGV4VHlwZSBuYW1lPSJkZXBlbmRlbmNpZXNUeXBlIj4K ICAgIDx4c2Q6c2VxdWVuY2U+CiAgICAgICA8eHNkOmVsZW1lbnQgbmFtZT0i ZGVwZW5kZW5jeSIgdHlwZT0iZGVwZWRlbmN5VHlwZSIgCiAgICAgICAgICBt aW5PY2N1cnM9IjEiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8+CiAgICA8L3hz ZDpzZXF1ZW5jZT4KPC94c2Q6Y29tcGxleFR5cGU+Cgo8eHNkOmNvbXBsZXhU eXBlIG5hbWU9InBsYXRmb3JtVHlwZSI+CiAgICA8eHNkOnNlcXVlbmNlPgog ICAgICAgPHhzZDplbGVtZW50IG5hbWU9ImRlcGVkZW5jeSIgdHlwZT0iZGVw ZWRlbmN5VHlwZSIKICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLz4KICAgIDwveHNkOnNlcXVlbmNlPgogICAgPHhzZDph dHRyaWJ1dGUgbmFtZT0ibmFtZSIgdHlwZT0icGxhdGZvcm1OYW1lVHlwZSIg dXNlPSJyZXF1aXJlZCIvPgogICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0iYXJj aCIgdHlwZT0icGxhdGZvcm1BcmNoVHlwZSIgdXNlPSJyZXF1aXJlZCIvPgo8 L3hzZDpjb21wbGV4VHlwZT4KCjx4c2Q6Y29tcGxleFR5cGUgbmFtZT0idmVy c2lvblR5cGUiPgogICAgPHhzZDpzZXF1ZW5jZT4KICAgICAgPHhzZDplbGVt ZW50IG5hbWU9InJlbGVhc2UtZGF0ZSIgdHlwZT0icmVsZWFzZURhdGVUeXBl IiAvPgogICAgICA8eHNkOmVsZW1lbnQgbmFtZT0icGxhdGZvcm0iIHR5cGU9 InBsYXRmb3JtVHlwZSIgCiAgICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9j Y3Vycz0idW5ib3VuZGVkIi8+CiAgICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJw cm92aWRlcyIgdHlwZT0icHJvdmlkZXNUeXBlIgogICAgICAgICAgbWluT2Nj dXJzPSIwIiBtYXhPY2N1cnM9IjEiIC8+CiAgICAgIDx4c2Q6ZWxlbWVudCBu YW1lPSJkZXBlbmRlbmNpZXMiIHR5cGU9ImRlcGVuZGVuY2llc1R5cGUiCiAg ICAgICAgICBtaW5PY2N1cnM9IjAiIG1heE9jY3Vycz0iMSIgLz4KICAgIDwv eHNkOnNlcXVlbmNlPgogICAgPHhzZDphdHRyaWJ1dGUgbmFtZT0icGtnX3Zl cnNpb24iIHR5cGU9InBhY2thZ2VWZXJzaW9uVHlwZSIgCiAgICAgICAgdXNl PSJyZXF1aXJlZCIvPgo8L3hzZDpjb21wbGV4VHlwZT4gICAgCgo8eHNkOmNv bXBsZXhUeXBlIG5hbWU9InBhY2thZ2VUeXBlIj4KICA8eHNkOnNlcXVlbmNl PgogICAgPHhzZDplbGVtZW50IG5hbWU9InN1bW1hcnkiIHR5cGU9InN1bW1h cnlUeXBlIiAvPgogICAgPHhzZDplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9u IiB0eXBlPSJkZXNjcmlwdGlvblR5cGUiIC8+CiAgICA8eHNkOmVsZW1lbnQg bmFtZT0iY2F0ZWdvcmllcyIgdHlwZT0iY2F0ZWdvcmllc1R5cGUiIAogICAg ICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLz4KICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJ2ZW5kb3IiIHR5cGU9InZlbmRvclR5cGUi IAoJbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIgLz4KICAg IDx4c2Q6ZWxlbWVudCBuYW1lPSJhdXRob3JzIiB0eXBlPSJhdXRob3JUeXBl IiAKICAgICAgICBtaW5PY2N1cnM9IjEiIG1heE9jY3Vycz0idW5ib3VuZGVk IiAvPgogICAgPHhzZDplbGVtZW50IG5hbWU9ImxpY2Vuc2VzIiB0eXBlPSJs aWNlbnNlVHlwZSIgCiAgICAgICAgbWluT2NjdXJzPSIxIiBtYXhPY2N1cnM9 InVuYm91bmRlZCIgLz4KICAgIDx4c2Q6ZWxlbWVudCBuYW1lPSJ2ZXJzaW9u IiB0eXBlPSJ2ZXJzaW9uVHlwZSIgCgltaW5PY2N1cnM9IjEiIG1heE9jY3Vy cz0idW5ib3VuZGVkIiAvPgogIDwveHNkOnNlcXVlbmNlPgoKICA8eHNkOmF0 dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJwYWNrYWdlTmFtZVR5cGUiLz4K ICA8eHNkOmF0dHJpYnV0ZSBuYW1lPSJ1cmwiIHR5cGU9InBhY2thZ2VIb21l VVJMVHlwZSIvPgo8L3hzZDpjb21wbGV4VHlwZT4KCjwhLS0gaW5zdGFudGlh dGUgZG9jdW1lbnQgLS0+Cgo8eHNkOmVsZW1lbnQgbmFtZT0icGFja2FnZSIg dHlwZT0icGFja2FnZVR5cGUiIC8+Cgo8L3hzZDpzY2hlbWE+CgoKCg== --0-375289087-1000235081=:52800-- From rnd@onego.ru Tue Sep 25 08:21:53 2001 From: rnd@onego.ru (Roman Suzi) Date: Tue, 25 Sep 2001 11:21:53 +0400 (MSD) Subject: [Catalog-sig] metadata schema In-Reply-To: <20010911190441.53237.qmail@web11604.mail.yahoo.com> Message-ID: On Tue, 11 Sep 2001, Kapil Thangavelu wrote: >attached is a xml schema for metadata. based loosely >off osd, xsa and debian's control files. i stayed away >from using namespaces for simplicity. Last evening I was thinking about Catalog. It occured to me, that there probably must be clear mathematical model of the Catalog. It will give hard-to-beat informational and algorithmic model almost automatically. I know, that Catalog effort is lagging because of over-design (and that is the reason why it is not quite there yet) but still this is very needed to design it right. I am sure that somewhere someone wrote nice dissertation on the topic of storing and retrieving interdependent components (and probably on the description of these data). Software components aren't standing still. They fork, merge, split into parts, join together in any proportions, etc., refactor in any thinkable way. And this data needs to be got based on the descriptions authors of the components write (because who else will do it) for individual versions of components. Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd@onego.ru _/ _/ Tuesday, September 25, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ ""How to Catch Worms" by Earl E. Bird" _/ From k_vertigo@yahoo.com Tue Sep 25 09:51:28 2001 From: k_vertigo@yahoo.com (Kapil Thangavelu) Date: Tue, 25 Sep 2001 01:51:28 -0700 (PDT) Subject: [Catalog-sig] metadata schema In-Reply-To: Message-ID: <20010925085128.87950.qmail@web11602.mail.yahoo.com> --- Roman Suzi wrote: > On Tue, 11 Sep 2001, Kapil Thangavelu wrote: > > >attached is a xml schema for metadata. based > loosely > >off osd, xsa and debian's control files. i stayed > away > >from using namespaces for simplicity. > > Last evening I was thinking about Catalog. It > occured to me, that there > probably must be clear mathematical model of the > Catalog. > It will give hard-to-beat informational and > algorithmic > model almost automatically. > > I know, that Catalog effort is lagging because of > over-design (and that is > the reason why it is not quite there yet) but still > this is very needed to > design it right. i've kinda given up on designing it right from the get go, some things need to be tested by fire. in an attempt to benefit from what others have done before i've taken a look at alot of real world implementations of package management and software catalogs. here's a sampling- # package management Yellow Dog Updater - http://sf.net/projects/yup Gentoo Linux's Portage - http://www.gentoo.org Debian's Apt RPM OpenACS's APM OSD # software catalogs Sourceforge - http://sf.net/projects/alexandria CPAN Freshmeat UDDI i had planned on writing this stuff up on a public wiki but zope.org apparently is transferring all of its content to a cmf based version in a month... > > I am sure that somewhere someone wrote nice > dissertation on the topic of > storing and retrieving interdependent components > (and probably on the > description of these data). actually there's another good parallel besides software components. the catalog is very much parallel to the webservices directory albeit with additional client implentation and metadata requirements. http://www.uddi.org if you find a good dissertation please post a link. cheers kapil thangavelu __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com From guido@python.org Tue Sep 25 14:18:21 2001 From: guido@python.org (Guido van Rossum) Date: Tue, 25 Sep 2001 09:18:21 -0400 Subject: [Catalog-sig] metadata schema In-Reply-To: Your message of "Tue, 25 Sep 2001 01:51:28 PDT." <20010925085128.87950.qmail@web11602.mail.yahoo.com> References: <20010925085128.87950.qmail@web11602.mail.yahoo.com> Message-ID: <200109251318.JAA13312@cj20424-a.reston1.va.home.com> > i had planned on writing this stuff up on a public > wiki but zope.org apparently is transferring all of > its content to a cmf based version in a month... AFAIK Wiki pages will still be supported and converted, so please don't hesitate. Otherwise, feel free to hijack a page of the (now largely unused) Python 2.2 MoinMoin at http://www.python.org/cgi-bin/moinmoin/ --Guido van Rossum (home page: http://www.python.org/~guido/) From k_vertigo@yahoo.com Sun Sep 30 01:08:42 2001 From: k_vertigo@yahoo.com (kapil thangavelu) Date: Sat, 29 Sep 2001 17:08:42 -0700 Subject: [Catalog-sig] metadata schema In-Reply-To: <200109251318.JAA13312@cj20424-a.reston1.va.home.com> References: <20010925085128.87950.qmail@web11602.mail.yahoo.com> <200109251318.JAA13312@cj20424-a.reston1.va.home.com> Message-ID: <200109292359.f8TNxQ091704@pimout4-int.prodigy.net> On Tuesday 25 September 2001 06:18 am, Guido van Rossum wrote: > > i had planned on writing this stuff up on a public > > wiki but zope.org apparently is transferring all of > > its content to a cmf based version in a month... > > AFAIK Wiki pages will still be supported and converted, so please > don't hesitate. ok, i've moved some content to a wiki on zope.org, its at http://www.zope.org/Members/k_vertigo/Stories/Gideon/FrontPage commenting open to all and editing open to zope.org members. its a bit weak on a lot of substance... probably the most interesting thing is the page on OtherSystems which still needs some fleshing out regarding OSD/XSA metadata formats. a data-model snapshot for postgres is also on the site at, its mainly a scratch pad i've been using for outlining relational structure... http://www.zope.org/Members/k_vertigo/Stories/Gideon/gideon-sql-snap.tgz cheers kapil From k_vertigo@yahoo.com Sun Sep 30 01:25:51 2001 From: k_vertigo@yahoo.com (kapil thangavelu) Date: Sat, 29 Sep 2001 17:25:51 -0700 Subject: [Catalog-sig] metadata In-Reply-To: <00a001c1349d$f0374b70$ae03a8c0@activestate.com> References: <20010831183938.51696.qmail@web11608.mail.yahoo.com> <00a001c1349d$f0374b70$ae03a8c0@activestate.com> Message-ID: <200109300016.f8U0Gaw201706@pimout1-int.prodigy.net> On Monday 03 September 2001 10:29 am, Andy McKay wrote: > > I spent some time looking at the metadata of some > > other packaging systems namely Debian's apt, ACS's > > apm, and the OSD format. > > Yep, we use the OSD format quite well in the perl and python packager > manager. OSD does alot of things well, but i have some questions/concerns about it and i'm also curious about active state's use. - is activestate the only company currently using OSD? - the use of version number seems very restrictive. there is an interesting discussion of version numbers in the DistUtils Version.py file. i'm not sure that enforcing a triple integer tuple of version numbers is realistic. - the lack of depedency classification. packages might have different levels of depedency ie SUGGEST/REQUIRES for example pygame. - the explicit hardcoding of mirrors for codebase - some of the values are a bit irrelevant to a python implementation like vm, and memsize. its obvious that osd was designed to be lean and mean for point and click installs, i think that this might not nesc. bethe case, and i think its important to support client specified levels of information. the information going from a package uploader does not nesc. equal the one going to a client downloading, since the catalog will need additional information for classification purposes (although this could be catalog maintainer supplied). but its also not evident that all clients will want the same level of information, a sysadmin might want to view a changelog, while a newbie might want a point and click install. i think the amount of metadata should be flexible to the client's request and osd doesn't offer that much by way of extended info (discounting additonal namespaces). most of my concerns regarding OSD could easily be solved by altering the format, i'm just curious how AS handles these things. - in what way does PPD differ from OSD? is it just a trimming down of the more esoteric features of OSD (mem, virtual machine,etc)? - the use of depedency specification refers the client to another osd file, without giving any indication of whats this represents? ie say i want to install narval which requires pyxml v0.6. i have pyxml0.6 installed i shouldn't have to grab another file without reason. the only alternative in OSD is sometype of file naming convention which requires the client manually parsing the url... of course this brings up an interesting question that i'm unsure how to deal with it. it applies more to the client and the server. namely how to deal with conflicting depedency versioning requirements. say in the case above the client has a newer version of a package than the requirements although the narval package might require the older version. how does pyppm deal with this on the client side? > > something else i was considering is a some type of > > global unique identifier to allow for replication of > > information to different repositories. i was thinking > > of something along the lines of a new uri protocol > > that identified a package on the basis of its > > clas sification with the catalog... i'm a little fuzzy > > on this. > > You probably dont want to make it unique on the classification since that > may change. CPAN uses > authors, which isn't too bad but we will be a little less strict on that. > Wouldn't the combination > of package name and version be good enough and reasonably permanent? my primary motivation for category based GUID was for replication purposes. i see it more now as a uri reference to a codebase which will allow for use of replicated servers, ie have /gui/pyqt be available from a number of replicated servers. i should qualify my use of the phrase replication. multi-master/peer-2-peer replication is hard, i think its probably easiest to ditch this and go with a master-> slave setup ala cpan. cheers kapil thangavelu From danm@ActiveState.com Sun Sep 30 03:25:45 2001 From: danm@ActiveState.com (Dan Milgram) Date: Sat, 29 Sep 2001 19:25:45 -0700 (PDT) Subject: [Catalog-sig] metadata In-Reply-To: <200109300016.f8U0Gaw201706@pimout1-int.prodigy.net> Message-ID: > OSD does alot of things well, but i have some questions/concerns about it > and i'm also curious about active state's use. > Let me preface by saying that the PPD format is based on OSD but isn't a 100% faithful rendition, and because it is an XML format it is naturally subject to change. > - is activestate the only company currently using OSD? > Hmm.. Not sure > - the use of version number seems very restrictive. there is an interesting > discussion of version numbers in the DistUtils Version.py file. i'm not sure > that enforcing a triple integer tuple of version numbers is realistic. > I agree. And the version.py file has a good approach for comparing versions - I think a lot of packages out there already adhere to version strings as in the StrictVersion class. It seems reasonable to make this the basis for allowable versions, and version comparison. The PPD format for version strings is too restrictive in its current incarnation. > - the lack of depedency classification. packages might have different levels > of depedency ie SUGGEST/REQUIRES for example pygame. > In practice I think this distinction will be made by a very minor fraction of packages out there. In any event this is easily solved by adding a "LEVEL" attribute that defaults to REQUIRES if not there. > - the explicit hardcoding of mirrors for codebase > This seems reasonable to me in this context > - some of the values are a bit irrelevant to a python implementation like vm, > and memsize. > Not in use... > most of my concerns regarding OSD could easily be solved by altering the > format, i'm just curious how AS handles these things. > > - in what way does PPD differ from OSD? is it just a trimming down of the more > esoteric features of OSD (mem, virtual machine,etc)? > Pretty much. There's an additional PYTHONCORE element to specify the language major minor version in order to handle pakcages with C extensions > - the use of depedency specification refers the client to another osd file, > without giving any indication of whats this represents? ie say i want to > install narval which requires pyxml v0.6. i have pyxml0.6 installed i > shouldn't have to grab another file without reason. the only alternative in > OSD is sometype of file naming convention which requires the client manually > parsing the url... > > of course this brings up an interesting question that i'm unsure how to deal > with it. it applies more to the client and the server. namely how to deal > with conflicting depedency versioning requirements. say in the case above the > client has a newer version of a package than the requirements although the > narval package might require the older version. how does pyppm deal with this > on the client side? > It doesn't :( pyppm is somewhat immature and doesn't deal with dependencies - this will be addressed by the python 2.2 release. ppm - the perl variant - does handle dependencies. Both versions maintain a cache or registry of sorts, so if a package has a dependency the cache is checked and the dependent package only need be downloaded if it isn't there. Dependent packages are specified with explicit an explicit version number as an attribute. This isn't as flexible as I'd like it to be. I don't know that there's a particularly good way to handle packages which require older versions but I think RPM and Deb packages are probably a better model to work off of eventually. That said, I think we want to think about this in an evolutionary way - there's only so much that can be tackled in the first go-around. Regards, Dan -- Dan Milgram/ActiveState Developer New! ASPN - ActiveState Programmer Network Essential programming tools and information http://www.ActiveState.com/ASPN