Hello,
I'm pleased to announce the second release of tmproc, a Topic Map
processor. This release is updated according to the final standard.
Suggestions and bug reports should be sent to: grove@infotek.no
Enjoy!
Geir O. Grønmo
--------------------------------------------------------------------------
Title: tmproc
Version: 0.20
Released: July 14th 1999
Author: Geir O. Grønmo, grove@infotek.no
Homepage: http://www.infotek.no/~grove/software/tmproc/index.html
- --
>>> What's new?
o This version supports the final release of the standard.
o Minor bugfixes
o Works with the Java Platform (JPython[1])
- --
>>> What is tmproc?
tmproc is an implementation of the new international standard ISO/IEC
13250 Topic Maps[2]. tmproc is written in Python, and should work on
any platform to which Python have been ported - including the Java
Platform.
- --
>>> What are Topic Maps?
'Topic Maps' is a new international standard (ISO/IEC 13250) for
layering multidimensional topic spaces on top of information
assets. The standard covers concepts like topics, associations,
occurrences and facets/metadata. Topic Maps are expected to have a
major impact on future information systems.
- --
>>> Features
o Import, export, query and manipulation of topic maps.
o Full set of extensible topic map classes with clearly defined
interfaces.
o Optional architectural processing [requires xmlarch].
o Introduction and reference documentation.
o Statistical and information printing classes
o Command line utility for interactive exploration
- --
>>> Requirements
- Python 1.5.1 or newer [3]
- An SGML/XML parser with a SAX driver
- SAX for Python [4]
- xmlarch 0.25, optional unless architectural processing is needed [5]
- --
>>> Licence
tmproc is free for both non-commercial and commercial
use. Redistribution of tmproc in commercial products requires another
licence. See [*] for detailed licence information.
- --
>>> References
[1] http://www.jpython.org/
[2] http://www.ornl.gov/sgml/SC34/
[3] http://www.python.org/
[4] http://www.stud.ifi.uio.no/~larsga/download/python/xml/saxlib.html
[5] http://www.infotek.no/~grove/software/xmlarch/index.html
[*] http://www.infotek.no/~grove/software/tmproc/licence.html
--------------------------------------------------------------------------
tmproc
0.20 - an implementation of Topic Maps, a new international
standard (ISO/IEC 13250:1999) for layering multidimensional topic spaces on
top of information assets. (14-Jul-1999)
From wask@mcc.com Wed Jul 14 23:09:36 1999
From: wask@mcc.com (wask@mcc.com)
Date: Wed, 14 Jul 1999 17:09:36 -0500
Subject: [XML-SIG] Parsing exception on CDATA
Message-ID:
Apologies in advance if this questionis old hat.
Why do I receive a
SAXParseException: Illegal construct
on
should be ignored.]]>
contained within
The Round Door
Tom Evans
1996
0-9546-0274-3
$23.00
An Intriguing Tale Of A Round Door In A Wall
should be ignored.]]>
Thanks,
Fred
From steve@renlabs.com Thu Jul 15 01:38:37 1999
From: steve@renlabs.com (Steven Work)
Date: 14 Jul 1999 17:38:37 -0700
Subject: [XML-SIG] Parsing exception on CDATA
In-Reply-To: wask@mcc.com's message of "Wed, 14 Jul 1999 17:09:36 -0500"
References:
Message-ID: <87yagi3fxu.fsf@solano.in.renlabs.com>
wask@mcc.com writes:
> should be ignored.]]>
Is a space allowed between 'CDATA' and '['?
--
Steven Work
Renaissance Labs
steve@renlabs.com
360 647-1833
From larsga@ifi.uio.no Thu Jul 15 06:45:11 1999
From: larsga@ifi.uio.no (Lars Marius Garshol)
Date: 15 Jul 1999 07:45:11 +0200
Subject: [XML-SIG] Parsing exception on CDATA
In-Reply-To:
References:
Message-ID:
* wask@mcc.com
|
| Why do I receive a
|
| SAXParseException: Illegal construct
|
| on
|
| should be ignored.]]>
^
Whitespace is not allowed before the second '[', which is what causes
the problem. Remove the space and you should be OK.
--Lars M.
From tpassin@idsonline.com Thu Jul 15 13:22:08 1999
From: tpassin@idsonline.com (Thomas B. Passin)
Date: Thu, 15 Jul 1999 08:22:08 -0400
Subject: : [XML-SIG] "&" and "<" within a string
Message-ID: <001001becebc$a9450980$5dfbb1cd@tpassinids>
On Tuesday, 13 July, wasc wrote:
>Subject: [XML-SIG] "&" and "<" within a string
>saxlib is throwing exceptions when I use "&" and "<" literally within an
>attribute value of type string, as it should.
>For example,
> name= "R&D library" value="/lib" />
>The XML spec says to use "&" and "<" when used literally in string.
>However, if I define
> name= "R&D library" value="<ROOT>/lib" />
>I still get an exception (apparently, the parser accepts the ">" and "/").
>Am I interpreting the spec correctly? Any suggestions?
>Thanks,
>Fred
Your problem is ill-formed XML, if your sample code is accurate. The following version works fine (meaning that it gets accepted by
the msxml parser, and by xt if you have an acceptable stylesheet):
Here is a stylesheet for the above xml that works with xt:
name:
value:
Here is the xt output:
C:>xt x1.xml x1.xsl
name: R&D library
value: <ROOT>/lib
Regards,
Thomas Passin
From tpassin@idsonline.com Thu Jul 15 13:26:28 1999
From: tpassin@idsonline.com (Thomas B. Passin)
Date: Thu, 15 Jul 1999 08:26:28 -0400
Subject: [XML-SIG] Re: XML-SIG digest, Vol 1 #331 - 3 msgs
Message-ID: <001101becebd$43fdcd40$5dfbb1cd@tpassinids>
-----Original Message-----
From: xml-sig-admin@python.org
To: xml-sig@python.org
Date: Wednesday, July 14, 1999 3:11 AM
Subject: XML-SIG digest, Vol 1 #331 - 3 msgs
>
>Send XML-SIG mailing list submissions to
> xml-sig@python.org
>
>To subscribe or unsubscribe via the web, visit
> http://www.python.org/mailman/listinfo/xml-sig
>or, via email, send a message with subject or body 'help' to
> xml-sig-request@python.org
>You can reach the person managing the list at
> xml-sig-admin@python.org
>
>When replying, please edit your Subject line so it is more specific than
>"Re: Contents of XML-SIG digest..."
>
>
>Today's Topics:
>
> 1. XML-DOM slow? (Mordy Ovits)
> 2. "&" and "<" within a string (wask@mcc.com)
> 3. Re: "&" and "<" within a string (Lars Marius Garshol)
>
>--__--__--
>
>Message: 1
>Date: Tue, 13 Jul 1999 12:23:56 -0400
>From: Mordy Ovits
>Organization: LockStar
>To: xml-sig@python.org
>Subject: [XML-SIG] XML-DOM slow?
>
>I've been playing around with the XML libraries, to great effect. I
>can't believe how useful it is. However, it seems to be very slow.
>The (short) program at the bottom of this email takes about 10 seconds
>to run!
>What am I doing wrong? Am I defaulting to a slow parser?
>Thanks!
>Mordy
>-----------------------------------------
>#!/usr/bin/python
>
>from xml.dom.html_builder import HtmlBuilder
>import urllib
>from sys import argv
>
>s = urllib.urlopen(argv[1])
>
>htmlstr = s.read()
>
>b = HtmlBuilder()
>
>b.ignore_mismatched_end_tags = 1
>b.feed(htmlstr)
>doc = b.document
>
>anchors = doc.getElementsByTagName('A')
>for a in anchors:
> if a._node.attributes.has_key("HREF"):
> href = a._node.attributes["HREF"]
> print "Title: ", a._node.children[0].value
> print "Link: ", href.children[0].value
> print
> else:
> print "error in (?)"
> print a._node.attributes
>-------------------
>--
>o Mordy Ovits
>o Cryptographic Engineer
>o LockStar Inc.
>---------------------------------------------------------------------------
>#!/usr/local/bin/python
>from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda
>x:x[:1]!=
>'-',a);d='-d'in
>a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
>while s:s=stdin.read(inb);s and map(stdout.write,map(lambda
>i,b=pow(reduce(
>lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))
>
>--__--__--
>
>Message: 2
>From: wask@mcc.com
>Reply-To:
>To: "'XML SIG'"
>Date: Tue, 13 Jul 1999 14:32:30 -0500
>charset="iso-8859-1"
>Subject: [XML-SIG] "&" and "<" within a string
>
>saxlib is throwing exceptions when I use "&" and "<" literally within an
>attribute value of type string, as it should.
>
>For example,
>
> name= "R&D library" value="/lib" />
>
>The XML spec says to use "&" and "<" when used literally in string.
>However, if I define
>
> name= "R&D library" value="<ROOT>/lib" />
>
>I still get an exception (apparently, the parser accepts the ">" and "/").
>
>Am I interpreting the spec correctly? Any suggestions?
>
>Thanks,
>
>Fred
>
>
>--__--__--
>
>Message: 3
>To: "'XML SIG'"
>Subject: Re: [XML-SIG] "&" and "<" within a string
>From: Lars Marius Garshol
>Date: 13 Jul 1999 21:47:43 +0200
>
>
>* wask@mcc.com
>|
>| saxlib is throwing exceptions when I use "&" and "<" literally
>| within an attribute value of type string, as it should.
>
>The first thing to realize is that it's not saxlib that does this, but
>whichever parser you are using.
>
>| However, if I define
>|
>| name= "R&D library" value="<ROOT>/lib" />
>|
>| I still get an exception (apparently, the parser accepts the ">" and
>| "/").
>|
>| Am I interpreting the spec correctly? Any suggestions?
>
>What is the exact error message? Where in the document is it thrown?
>And what does your document really look like? (The example above seems
>to have some non-fatal typos.)
>
>Sorry to be so unhelpful, but I found this message impossible to
>decipher.
>
>--Lars M.
>
>
>
>
>End of XML-SIG Digest
From ajung@sz-sb.de Fri Jul 16 11:52:30 1999
From: ajung@sz-sb.de (Andreas Jung)
Date: Fri, 16 Jul 1999 12:52:30 +0200
Subject: [XML-SIG] sgmllib has problems with dots in tag names
Message-ID: <19990716125230.A14994@sz-sb.de>
The SGML parsers from the standard sgmllib and the XML sgmllib war both
unable to parse SGML tags with dots in the tag name like . The
parsers callback functions only get the first part of the tag name (before
the dot) as argument (in this case 'TI'). Because the tags are valid SGML
tags this is a bit annoying. Ok, one could get a workaround by replacing
all dots in tags with an underscore however that's not a clean solution :-)
Any others ideas ?
Thanks,
Andreas
From Fred L. Drake, Jr."
References: <19990716125230.A14994@sz-sb.de>
Message-ID: <14223.12495.910694.301072@weyr.cnri.reston.va.us>
Andreas Jung writes:
> The SGML parsers from the standard sgmllib and the XML sgmllib war both
> unable to parse SGML tags with dots in the tag name like . The
> parsers callback functions only get the first part of the tag name (before
> the dot) as argument (in this case 'TI'). Because the tags are valid SGML
> tags this is a bit annoying. Ok, one could get a workaround by replacing
> all dots in tags with an underscore however that's not a clean solution :-)
Andreas,
Ok, I've poked at the standard sgmllib a bit to see what the problem
is. The parser is recognizing the start and end tags. Once
recognized, it is looking for the handler methods start_*() / end_*()
or do_*(). Since there's a dot in the name, these methods are not
defined, and the unknown_*tag() methods are called instead of the
handle_*tag() methods.
It should be easy to override the unknown_*tag() methods to use a
table-based dispatcher or performs some form or name mangling, then
passes known tags through to the handle_*tag() methods or whatever.
This seems to be the easiest way to deal with the situation in the
short term.
If you have any suggestions for a better approach to take, I'd love
to hear it. It may not be unreasonable to use a mechanism similar to
that used by xmllib (a table of registered handler methods).
-Fred
--
Fred L. Drake, Jr.
Corporation for National Research Initiatives
From ajung@sz-sb.de Fri Jul 16 14:33:24 1999
From: ajung@sz-sb.de (Andreas Jung)
Date: Fri, 16 Jul 1999 15:33:24 +0200
Subject: [XML-SIG] sgmllib has problems with dots in tag names
In-Reply-To: <14223.12495.910694.301072@weyr.cnri.reston.va.us>; from Fred L. Drake on Fri, Jul 16, 1999 at 09:17:03AM -0400
References: <19990716125230.A14994@sz-sb.de> <14223.12495.910694.301072@weyr.cnri.reston.va.us>
Message-ID: <19990716153323.A23945@sz-sb.de>
On Fri, Jul 16, 1999 at 09:17:03AM -0400, Fred L. Drake wrote:
>
> Ok, I've poked at the standard sgmllib a bit to see what the problem
> is. The parser is recognizing the start and end tags. Once
> recognized, it is looking for the handler methods start_*() / end_*()
> or do_*(). Since there's a dot in the name, these methods are not
> defined, and the unknown_*tag() methods are called instead of the
> handle_*tag() methods.
> It should be easy to override the unknown_*tag() methods to use a
> table-based dispatcher or performs some form or name mangling, then
> passes known tags through to the handle_*tag() methods or whatever.
> This seems to be the easiest way to deal with the situation in the
> short term.
That's a solution that works with the standard sgmllib from the Python
distribution. However this solution does not work with sgmllib from
xml.parsers. I'm not sure if tag names with dots in their names are valid in XML
or not. So this might explain the different behaviour however I don't think
that's the reason. Maybe I'll find the real reason over the weekend.
Andreas
--
_\\|//_
(' O-O ')
------------------------------ooO-(_)-Ooo--------------------------------------
Andreas Jung, Saarbrücker Zeitung Verlag und Druckerei GmbH
Saarbrücker Daten-Innovations-Center
Gutenbergstr. 11-23, D-66103 Saarbrücken, Germany
Phone: +49-(0)681-502-1563, Fax: +49-(0)681-502-1509
Email: ajung@sz-sb.de (PGP key available)
-------------------------------------------------------------------------------
From sean@digitome.com Fri Jul 16 12:45:39 1999
From: sean@digitome.com (Sean Mc Grath)
Date: Fri, 16 Jul 1999 12:45:39 +0100
Subject: [XML-SIG] sgmllib has problems with dots in tag names
In-Reply-To: <19990716125230.A14994@sz-sb.de>
Message-ID: <3.0.6.32.19990716124539.0098d810@gpo.iol.ie>
At 12:52 16/07/99 +0200, you wrote:
>The SGML parsers from the standard sgmllib and the XML sgmllib war both
>unable to parse SGML tags with dots in the tag name like . The
>parsers callback functions only get the first part of the tag name (before
>the dot) as argument (in this case 'TI'). Because the tags are valid SGML
>tags this is a bit annoying. Ok, one could get a workaround by replacing
>all dots in tags with an underscore however that's not a clean solution :-)
>
If you want callbacks named after element types, then there is no way
out other than to do some name mangling. There are lots of characters
valid in SGML/XML element type names that are not legal in function/method
names. Characters like "-" and "." are popular ones:-)
The SAX way is to have a generic element handler to which the
element type name is passed as a String. This gets round the
problem but is sooooo much less convenient than the element
specific callback approach.
Developers Day Co-Chair, 9th International World Wide Web Conference
16-19, May, 2000, Amsterdam, The Netherlands http://www9.org
From nico@salience.nl Mon Jul 19 09:17:54 1999
From: nico@salience.nl (N.A.F.M. Poppelier)
Date: Mon, 19 Jul 1999 10:17:54 +0200
Subject: [XML-SIG] Re: sgmllib has problems with dots in tag names (XML-SIG digest, Vol 1
#334)
References: <199907170502.BAA05493@python.org>
Message-ID: <3792DF32.83AEAC6E@salience.nl>
This is a multi-part message in MIME format.
--------------F4638FB6F8782776CFD7230F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
xml-sig-admin@python.org wrote:
> That's a solution that works with the standard sgmllib from the Python
> distribution. However this solution does not work with sgmllib from
> xml.parsers. I'm not sure if tag names with dots in their names are valid in XML
> or not.
> If you want callbacks named after element types, then there is no way
> out other than to do some name mangling. There are lots of characters
> valid in SGML/XML element type names that are not legal in function/method
> names. Characters like "-" and "." are popular ones:-)
As anyone with a Web browser can verify, version 1.0 of the XML standard
defines
a name (appearing in a start tag or end tag, for example) as "a token
beginning with a letter or one of a few punctuation characters, and
continuing
with letters, digits, hyphens, underscores, colons, or full stops,
[...]".
It is natural to use the element name or tag name as the default name
to generate a function or method name. But in cases where the name space
of the programming language used is not identical to the name space of
XML, some escape mechanism must be in place. One possibility is to
allow the user to specify a map from XML name to function/method name,
and use the value from this map, if it exists, and otherwise use the
default based on the XML name.
Nico
--------------F4638FB6F8782776CFD7230F
Content-Type: text/x-vcard; charset=us-ascii;
name="nico.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for N.A.F.M. Poppelier
Content-Disposition: attachment;
filename="nico.vcf"
begin:vcard
n:Poppelier;Nico
tel;pager:-
tel;cell:06-20412666
tel;fax:-
tel;home:-
tel;work:030-6056675
x-mozilla-html:FALSE
url:http://www.salience.nl
org:Salience
adr:;;Villawal 21;Nieuwegein;;;The Netherlands
version:2.1
email;internet:nico@salience.nl
title:project manager SGML/XML
note;quoted-printable:''The new pond=0D=0AA frog jumps in=0D=0ADeadly silence''
fn:Nico Poppelier
end:vcard
--------------F4638FB6F8782776CFD7230F--
From movits@lockstar.com Mon Jul 19 21:00:41 1999
From: movits@lockstar.com (Mordy Ovits)
Date: Mon, 19 Jul 1999 13:00:41 -0700
Subject: [XML-SIG] Uche Ogbuji in today's New York Times
Message-ID: <379383E9.45ED9DC2@lockstar.com>
He's in the front page article in the Business section. 'Twas way cool to see a
fellow pythoneer in the NYT :-)
Mordy
--
o Mordy Ovits
o Cryptographic Engineer
o LockStar Inc.
---------------------------------------------------------------------------
#!/usr/local/bin/python
from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
'-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))
From Jean-Michel.Bruel@univ-pau.fr Thu Jul 22 10:20:00 1999
From: Jean-Michel.Bruel@univ-pau.fr (Jean-Michel BRUEL)
Date: Thu, 22 Jul 1999 11:20:00 +0200 (MET DST)
Subject: [XML-SIG] [CFP:] OOPSLA'99 Workshop
Message-ID: <199907220920.LAA12325@crisv4.univ-pau.fr>
[apologies if you receive multiple copies of this announcement]
=================================================================
Call for Papers
=================================================================
OOPSLA'99 Workshop on
Rigorous Modeling and Analysis with the UML: Challenges
and Limitations
Workshop #23
DENVER, COLORADO
Tuesday, November 2nd, 1999
------------------------------
workshop website: http://www.univ-pau.fr/OOPSLA99
- o 0 o -
WORKSHOP OVERVIEW
==================
The UML is a standard object modeling language that is
targeted at large, complex systems. The high quality experiences
embedded in the UML certainly makes
its application to complex systems desirable, but the lack of precise
semantics that support rigorous semantic analyses can limit its effectiveness.
The modeling of complex systems requires the use of
modeling constructs that provide complexity management mechanisms and that
allow for the early detection of errors in requirements and designs.
The separation of views principle has proven to be an effective means of
controlling complexity and is well-supported by the UML. On the other hand,
the formality and rigor principle that facilitates the detection of errors in
requirements and designs is not well-supported in the UML.
The purpose of the proposed workshop is to bring together
researchers and practitioners from academia and industry to
discuss the semantic foundations of the UML as described in
the OMG-UML documentation (current version is 1.3).
Presentations and discussions will focus on identifying deficiencies
in the UML semantics foundation, analyzing proposed approaches
to addressing the deficiencies, understanding UML limitations and
identifying the challenges that will have to be met in making the
UML a rigorous modeling notation. Particular attention will be paid
to the meta-modeling approach to semantics and to the OCL.
TOPICS
=======
The workshop topics include:
* Semantic foundations for UML static and dynamic models
* Use of meta-models to express semantics
* Semantic foundations for the OCL
* Using the OCL to support rigorous reasoning
* UML support for rigorous development of software (including
support for the use of software architectures and frameworks)
FORMAT
=======
This workshop is the second of a planned series of workshops on
strengthening the UML semantic foundation. The first workshop was
held at ECOOP'99 (see
http://www.cs.ukc.ac.uk/people/staff/sjhk/detail/ecoop99/UMLsemanticsFAQ/index.html).
The first workshop focused primarily on the utility of having precise
semantics. In the OOPSLA'99 workshop the focus will be on the semantic
foundations of the UML notations.
The workshop will consist mainly of working groups that
focus on a specific problem. There will be at least three invited
presentations that highlight UML deficiencies and proposed development
paths for the UML. The presentations, given in the first
hour of the workshop, will provide some of the
context for much of the discussions in the working groups. The
working groups will be determined by the submissions to the workshop
and will be announced at least 1 week before the workshop starts.
SUBMISSIONS & PARTICIPATION
============================
Attendance will be by invitation only. If you would like to be considered
for participation you are asked to prepare a statement outlining your
perception of the UML semantics and the use of the UML for
rigorous modeling. Statements on the following topics are especially
welcome:
(1) deficiencies in the UML semantics,
(2) expressing semantics using meta-models,
(3) OCL semantics,
(4) analysis of OCL expressions (including
proposals for automated support for analysis),
(5) using the UML for rigorous specification and analysis,
(6) providing automated support for rigorous analysis of UML models.
Send submissions via email to oopsla99@in.tum.de. Submissions
should not exceed 2 pages (10 pt., single space) and
should be in one of the following formats:
* Plain text
* Postscript
* .pdf formats
Accepted submissions will be placed on the workshop website
(http://www.univ-pau.fr/OOPSLA99).
IMPORTANT DATES
================
Submission deadline: September 10th, 1999
Notification date: October 1st, 1999
Workshop date: November 2nd, 1999
ORGANIZERS
===========
This workshop is organized by members the Precise UML (pUML) group
(http://www.cs.york.ac.uk/puml).
Workshop Coordinators
----------------------
Robert France, Organizing Chair
Department of Computer Science
Colorado State University
Fort Collins, CO 80523-1873.
phone: 970-491-6356
fax: 970-491-2466
Email: france@cs.colostate.edu
Bernhard Rumpe, Program Co-Chair
Faculty for Computer Science
Technische Universität München
D-80333 Munich, Germany.
Phone: +49 -89 -289-28129
Fax: +49 -89 -289-28183
Email: rumpe@in.tum.de
Brian Henderson-Sellers, Program Co-Chair
Director, Centre for Object Technology Applications and Research
and Professor of Information Systems
School of Computing Sciences
University of Technology, Sydney, Australia.
phone: +61 (0)2 9514 1687
fax: +61 (0)2 9514 1807
Email: brian@socs.uts.edu.au
Jean-Michel Bruel, Publicity Chair & On-site Coordinator
Laboratoire T.A.S.C.
Université de Pau et des Pays de l'Adour
F-64000 Pau, France.
phone: +33(0)5.59.92.31.89
fax: +33(0)5.59.80.83.74
Email: Jean-Michel.Bruel@univ-pau.fr
Ana Moreira, On-site Coordinator
Departamento de Informática
Faculdade de Ciencias e Tecnologia
Universidade Nova de Lisboa
2825 Monte da Caparica, Portugal
phone: +351-1-294 85 36 Ext. 0716
fax: +351-1-294 85 41
email: amm@di.fct.unl.pt
From wask@mcc.com Thu Jul 22 17:22:12 1999
From: wask@mcc.com (wask@mcc.com)
Date: Thu, 22 Jul 1999 11:22:12 -0500
Subject: [XML-SIG] XML Package dependency on Python
Message-ID:
Hello, all --
I am running the XML package in conjunction with JPython. Since the JPython
site states that a lot of the Python capability is found within JPython, I
decided not to install Python.
However, the parser search capability within saxexts depends upon the import
functionality found in imp. As imp is not implemented in JPython, I am
forced to install Python just to get the ability to search for a parser.
Is my understanding correct? While memory is not an issue, this seems to be
adding unnecessary complexity to the JPython environment build process.
--- Fred
From jefftc@leland.Stanford.EDU Thu Jul 22 20:29:10 1999
From: jefftc@leland.Stanford.EDU (Jeffrey Chang)
Date: Thu, 22 Jul 1999 12:29:10 -0700 (PDT)
Subject: [XML-SIG] insert_whitespace function
Message-ID:
Hello everybody,
I've written an insert_whitespace function that complements the
functionality of xml.dom.utils.strip_whitespace. Given a DOM tree with no
extraneous whitespace, it will insert some so that the tree can be printed
prettily with toxml().
I hope that this would eventually be added to the utils.py file as I
believe it is useful.
I do not have any really elaborate XML documents to test this on, so if
you find some cases where this function fails, please send them to me.
Thanks,
Jeff
from xml.dom import core
def insert_whitespace(node, spacing=2, indent=0):
"""insert_whitespace(node[, spacing=2])
Format a DOM tree prettily by inserting whitespace where appropriate.
spacing specifies the number of spaces to indent.
This assumes that the tree has been stripped of whitespace.
"""
indented_types = [core.ELEMENT_NODE, # which node types to indent
core.PROCESSING_INSTRUCTION,
core.COMMENT_NODE]
doc = node.get_ownerDocument()
if(doc is None): # I'm the root node, start the recursion
for child in node.childNodes[:]:
insert_whitespace(child, spacing=spacing, indent=indent)
return
indent_str = "\n" + " "*(indent+spacing)
indented=0 # has anything been indented?
for child in node.childNodes[:]:
if(child.nodeType in indented_types):
node.insertBefore(doc.createTextNode(indent_str), child)
indented=1
insert_whitespace(child, spacing=spacing, indent=indent+spacing)
if(indented): # need to indent my close tag
node.appendChild(doc.createTextNode("\n" + " "*indent))
From Amos@digicool.com Thu Jul 22 21:52:46 1999
From: Amos@digicool.com (Amos Latteier)
Date: Thu, 22 Jul 1999 16:52:46 -0400
Subject: [XML-SIG] ANNOUNCE: XMLDocument 1.0a1
Message-ID: <613145F79272D211914B0020AFF640190AD2CA@gandalf.digicool.com>
I am pleased to announce the first alpha release of XML Document. XML
Document allows you to use xml objects in the Zope environment. You can
create xml documents in Zope and leverage Zope to format, query, and
manipulate xml.
http://www.zope.org/Download/XMLDocument
This release requires Zope 2.0x and the pyexpat parser which will be
distributed with Zope come Zope 2.0b1. Until the Zope beta release you
can get pyexpat from the Python xml-sig's xml package.
http://www.python.org/sigs/xml-sig
I'd love feedback on the functionality and design of this product. I
think that it has a lot of potential. Also I encourage contributions on
this project since I do not have a lot of time to spend on it myself.
Happy xml hacking!
-Amos
P.S. Install it like a normal Zope product, i.e. ungzip and untar in
inside your Zope directory. If you are using the xml-sig pyexpat, Zope
will expect to find it in xml.parsers.pyexpat.
--
Amos Latteier mailto:amos@digicool.com
Digital Creations http://www.digicool.com
From wask@mcc.com Thu Jul 22 22:02:50 1999
From: wask@mcc.com (wask@mcc.com)
Date: Thu, 22 Jul 1999 16:02:50 -0500
Subject: [XML-SIG] Inconsistent module names
Message-ID:
[Apologies in advance if this topic has been thrashed out before.]
Hardcoded in saxexts (see below) is the expanded module name for parser
drivers, which implies that the xml directory structure in Windows is
(root)\xml\sax\drivers
Yet when I unzip the dowload, the files go into the ...\xml-0.5.1 directory.
Thus, it takes some time to fgigure out to rename the directory to "xml".
I know this is a nit but it is the type of thing that discredits software in
the business world.
--- Fred
# --- Creating parser factories
XMLParserFactory=ParserFactory(["xml.sax.drivers.drv_pyexpat",
"xml.sax.drivers.drv_xmltok",
"xml.sax.drivers.drv_xmlproc",
"xml.sax.drivers.drv_xmltoolkit",
"xml.sax.drivers.drv_xmllib",
"xml.sax.drivers.drv_xmldc",
"xml.sax.drivers.drv_sgmlop"])
XMLValParserFactory=ParserFactory(["xml.sax.drivers.drv_xmlproc_val"])
HTMLParserFactory=ParserFactory(["xml.sax.drivers.drv_htmllib",
"xml.sax.drivers.drv_sgmlop",
"xml.sax.drivers.drv_sgmllib"])
SGMLParserFactory=ParserFactory(["xml.sax.drivers.drv_sgmlop",
"xml.sax.drivers.drv_sgmllib"])
From Fred L. Drake, Jr."
References:
Message-ID: <14231.35552.403804.460987@weyr.cnri.reston.va.us>
wask@mcc.com writes:
> Yet when I unzip the dowload, the files go into the ...\xml-0.5.1 directory.
>
> Thus, it takes some time to fgigure out to rename the directory to "xml".
I think this is a really annoying thing; the Python package
directory is used as a general dumping ground for a bunch of stuff
other than the actual package code. (README, documentation and demo
directories, etc.)
I think the right approach is to have a distribution directory that
contains the package directory and the other stuff. For those of use
that use a CVS checkout named "xml", we'd get something like:
xml/demos/
docs/
README
xml/
The packaged distribution should end up like this:
xml-VERSION/demos/
docs/
README
xml/
This is the way the distutils tree is laid out (in part because I
pressured Greg to do it that way;).
Does anyone else agree? Alternatives?
-Fred
--
Fred L. Drake, Jr.
Corporation for National Research Initiatives
From scott@chronis.pobox.com Thu Jul 22 22:48:12 1999
From: scott@chronis.pobox.com (Scott Cotton)
Date: Thu, 22 Jul 1999 17:48:12 -0400
Subject: [XML-SIG] Inconsistent module names
In-Reply-To: <14231.35552.403804.460987@weyr.cnri.reston.va.us>; from Fred L. Drake on Thu, Jul 22, 1999 at 05:19:28PM -0400
References: <14231.35552.403804.460987@weyr.cnri.reston.va.us>
Message-ID: <19990722174811.A826@chronis.pobox.com>
On Thu, Jul 22, 1999 at 05:19:28PM -0400, Fred L. Drake wrote:
|
| wask@mcc.com writes:
| > Yet when I unzip the dowload, the files go into the ...\xml-0.5.1 directory.
| >
| > Thus, it takes some time to fgigure out to rename the directory to "xml".
|
| I think this is a really annoying thing; the Python package
| directory is used as a general dumping ground for a bunch of stuff
| other than the actual package code. (README, documentation and demo
| directories, etc.)
| I think the right approach is to have a distribution directory that
| contains the package directory and the other stuff. For those of use
| that use a CVS checkout named "xml", we'd get something like:
|
| xml/demos/
| docs/
| README
| xml/
|
| The packaged distribution should end up like this:
|
| xml-VERSION/demos/
| docs/
| README
| xml/
|
| This is the way the distutils tree is laid out (in part because I
| pressured Greg to do it that way;).
| Does anyone else agree? Alternatives?
Absolutely. I've switched back and forth between both
repository organization types for several projects at work,
and separating the source from the README, etc. has turned
out to be *much* better in practice. What it comes down to
for me is that the source is always a distinct category when
compared to all the non-source parts of a project, so it
always works well when there are any non-source files in a
repository. The other way just confuses the issue of what
the source when browsing the directory structure of a
repository.
scott
From niko@cmsplatform.com Fri Jul 23 00:07:38 1999
From: niko@cmsplatform.com (Nik O)
Date: Thu, 22 Jul 1999 17:07:38 -0600
Subject: [XML-SIG] Inconsistent module names
Message-ID: <010201bed497$0a067c60$1a5e360a@tetondata.com>
Scott Cotton wrote:
>
>I've switched back and forth between both repository organization
>types for several projects at work, and separating the source from
>the README, etc. has turned out to be *much* better in practice.
Absolutely agreed. My years of developing software and managing groups of
progs and non-progs (e.g. artists, tech writers) have convinced me that the
most functional project/program/thing tree structure is:
./foo <== .bin, .exe, .html, .ini, _whatever_it_takes_to_run_foo
/docuser <== "end-user" doc: readme, .doc, .txt, .html,
_whatever_enduser_reads
/docdev <== "developer" doc: readme, .doc, .txt, .html,
_whatever_developer_reads
/source <== .c, .h, .rc, .py, .lib, .mak, .prj,
_whatever_prog_needs_to_build_foo
/object <== .obj, .map, _any_build_foo_process_temps
Sometimes a "./foo/images", or "./foo/prefs", or something similar is useful
to further organize the "_whatever_it_takes_to_run_foo" stuff. With the
above structure, it is very simple to prune branches that aren't pertinent
to a specific release package, e.g., "end-users" would get only "./foo",
"./foo/docuser", and "./foo/images", whilst a developer might get the entire
tree, and a tech writer might get just the "./foo" and "./foo/doc*"
branches.
Hope y'all will forgive my obvious C bias -- i don't really use Python that
much, but XML is XML, and software engineering is software engineering.
Regards,
-Nik O, Content Mgmt Solutions, Jackson, Wyo.
From larsga@ifi.uio.no Fri Jul 23 06:35:45 1999
From: larsga@ifi.uio.no (Lars Marius Garshol)
Date: 23 Jul 1999 07:35:45 +0200
Subject: [XML-SIG] Inconsistent module names
In-Reply-To: <14231.35552.403804.460987@weyr.cnri.reston.va.us>
References: <14231.35552.403804.460987@weyr.cnri.reston.va.us>
Message-ID:
* Fred L. Drake
|
| The packaged distribution should end up like this:
|
| xml-VERSION/demos/
| docs/
| README
| xml/
|
| [...]
| Does anyone else agree? Alternatives?
I agree. The tree as it is now is too flat and there's too much stuff
in the root directory anyway, quite apart from the fact that it mixes
up the sources with other things.
--Lars M.
From wask@mcc.com Fri Jul 23 17:23:02 1999
From: wask@mcc.com (wask@mcc.com)
Date: Fri, 23 Jul 1999 11:23:02 -0500
Subject: [XML-SIG] More on XML / Python dependencies
Message-ID:
Hello, again ---
The other day I sent the following:
> I am running the XML package in conjunction with JPython. Since the
JPython
> site states that a lot of the Python capability is found within JPython, I
> decided not to install Python.
> However, the parser search capability within saxexts depends upon the
import
> functionality found in imp. As imp is not implemented in JPython, I am
> forced to install Python just to get the ability to search for a parser.
With a replacement for saxexts that I was directed to, I obtain "imp" from
org.python.core, not Python.
for parser_name in list:
if sys.platform[:4] == "java":
try:
from org.python.core import imp
However, I'm still forced into the Python environment in the next statement:
drv_module = imp.importName(parser_name, 0, globals())
(An exception I got was that urllib couldn't be found. On my machine, that
module is in Python's \Lib directory.)
I'm not haggling over code. Rather, I wish to raise the question whether or
not there are plans afoot to decouple XML from Python? This issue is more
than that of what type of files are stored in which directories.
I raise this question as I have a customer whom I'm trying to convince to
use JPython. I told him he didn't need to install Python. Currently, that is
wrong when using the XML package.
Please understand that I am not criticizing - I'm just trying to get a
better understanding of the environment.
--- Fred
From larsga@ifi.uio.no Fri Jul 23 18:02:34 1999
From: larsga@ifi.uio.no (Lars Marius Garshol)
Date: 23 Jul 1999 19:02:34 +0200
Subject: [XML-SIG] More on XML / Python dependencies
In-Reply-To:
References:
Message-ID:
* wask@mcc.com
|
| However, I'm still forced into the Python environment in the next
| statement:
|
| drv_module = imp.importName(parser_name, 0, globals())
|
| (An exception I got was that urllib couldn't be found. On my
| machine, that module is in Python's \Lib directory.)
You can use the Python libraries with JPython. (Well, most of them.)
See step 3 on for a
description of how.
| I'm not haggling over code. Rather, I wish to raise the question
| whether or not there are plans afoot to decouple XML from Python?
Fred, I don't understand this question at all. What do you mean by
decoupling XML from Python? After all, it is 100% independent of
Python, and all we're doing is making software for working with it
inside Python.
--Lars M.
From wask@mcc.com Fri Jul 23 19:01:45 1999
From: wask@mcc.com (wask@mcc.com)
Date: Fri, 23 Jul 1999 13:01:45 -0500
Subject: [XML-SIG] More on XML / Python dependencies
In-Reply-To:
Message-ID:
Lars --
You wrote:
> You can use the Python libraries with JPython. (Well, most of them.)
> See step 3 on description of how.
Looks like I'm guilty of the old adage: "When all else fails, read the
directions!"
> Fred, I don't understand this question at all. What do you mean by
> decoupling XML from Python? After all, it is 100% independent of
> Python, and all we're doing is making software for working with it
> inside Python.
I guess I'm splitting hairs. Perhaps "bundle" would be more accurate than
"couple". My point is that in order to use the XML package with JPython, I
must:
1.) install JPython (java JPython11beta2)
2.) install the XML package (unzip xml-0_5_1.tgz)
3.) install the necessary Python libraries (jpython -jar pylib152b.jar)
Why go through step 3? Why not simply *bundle* those libraries with JPython?
I'm off of my soap box. Have a good weekend.
--- Fred
From Fred L. Drake, Jr."
References:
Message-ID: <14232.44850.850721.281778@weyr.cnri.reston.va.us>
wask@mcc.com writes:
> I guess I'm splitting hairs. Perhaps "bundle" would be more accurate than
> "couple". My point is that in order to use the XML package with JPython, I
> must:
>
> 1.) install JPython (java JPython11beta2)
> 2.) install the XML package (unzip xml-0_5_1.tgz)
> 3.) install the necessary Python libraries (jpython -jar pylib152b.jar)
>
> Why go through step 3? Why not simply *bundle* those libraries with JPython?
Fred,
This seems to be entirely a JPython packaging issue. I've forwarded
your message to Barry Warsaw (bwarsaw@python.org), the JPython
maintainer.
-Fred
--
Fred L. Drake, Jr.
Corporation for National Research Initiatives
From grove@infotek.no Sun Jul 25 23:19:48 1999
From: grove@infotek.no (Geir Ove Grønmo)
Date: 26 Jul 1999 00:19:48 +0200
Subject: [XML-SIG] XML Package dependency on Python
In-Reply-To:
References:
Message-ID:
* wask@mcc.com
| Hello, all --
|
| I am running the XML package in conjunction with JPython. Since the JPython
| site states that a lot of the Python capability is found within JPython, I
| decided not to install Python.
|
| However, the parser search capability within saxexts depends upon the import
| functionality found in imp. As imp is not implemented in JPython, I am
| forced to install Python just to get the ability to search for a parser.
|
| Is my understanding correct? While memory is not an issue, this seems to be
| adding unnecessary complexity to the JPython environment build process.
http://www.infotek.no/~grove/saxexts.py should fix this.
Geir O.
From akuchlin@mems-exchange.org Tue Jul 27 14:47:04 1999
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 27 Jul 1999 09:47:04 -0400 (EDT)
Subject: [XML-SIG] Inconsistent module names
In-Reply-To:
References:
<14231.35552.403804.460987@weyr.cnri.reston.va.us>
Message-ID: <14237.47192.803781.479900@amarok.cnri.reston.va.us>
Lars Marius Garshol quoted:
>* Fred L. Drake
>| The packaged distribution should end up like this:
>| xml-VERSION/demos/
>| docs/
>| README
>| xml/
OK; I'll try to get around to doing this. (People with commit
privileges can feel free to do it for me, too.)
--
A.M. Kuchling http://starship.python.net/crew/amk/
A committee is a cul-de-sac down which ideas are lured and then quietly
strangled.
-- Sir Barnett Cocks
From Fred L. Drake, Jr."
References:
<14231.35552.403804.460987@weyr.cnri.reston.va.us>
<14237.47192.803781.479900@amarok.cnri.reston.va.us>
Message-ID: <14237.47779.965703.944976@weyr.cnri.reston.va.us>
Andrew M. Kuchling writes:
> OK; I'll try to get around to doing this. (People with commit
> privileges can feel free to do it for me, too.)
This kind of operation is most easily done by someone who can reach
into the actual repository using "mv" and the like... ;-)
Which is not to say that's a *good* way to do it. Since it will
probably take a little while and may be disconcerting for people with
modified working files, we should probably agree at least about who
will do it and give 24 hours notice so people can get changes checked
in beforehand if desired.
I'm willing to do it the right way toward the end of the week if
that works for people.
-Fred
--
Fred L. Drake, Jr.
Corporation for National Research Initiatives
From akuchlin@mems-exchange.org Tue Jul 27 14:59:58 1999
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 27 Jul 1999 09:59:58 -0400 (EDT)
Subject: [XML-SIG] Inconsistent module names
In-Reply-To: <14237.47779.965703.944976@weyr.cnri.reston.va.us>
References:
<14231.35552.403804.460987@weyr.cnri.reston.va.us>
<14237.47192.803781.479900@amarok.cnri.reston.va.us>
<14237.47779.965703.944976@weyr.cnri.reston.va.us>
Message-ID: <14237.47966.313734.724853@amarok.cnri.reston.va.us>
Fred L. Drake writes:
> This kind of operation is most easily done by someone who can reach
>into the actual repository using "mv" and the like... ;-)
That's a problem, because the repository is on lyra.org, to
which only Greg Stein would have telnet access. Instead, I could
disable all mail delivery for xml-checkins subscribers before moving
things around, so that people don't get buried in a mass of CVS
messages, and then enable mail delivery again.
--
A.M. Kuchling http://starship.python.net/crew/amk/
A machine is as distinctively and brilliantly and expressively human as a
violin sonata or a theorem in Euclid.
-- Gregory Vlastos
From Fred L. Drake, Jr."
References:
<14231.35552.403804.460987@weyr.cnri.reston.va.us>
<14237.47192.803781.479900@amarok.cnri.reston.va.us>
<14237.47779.965703.944976@weyr.cnri.reston.va.us>
<14237.47966.313734.724853@amarok.cnri.reston.va.us>
Message-ID: <14237.48978.888773.991401@weyr.cnri.reston.va.us>
Andrew M. Kuchling writes:
> That's a problem, because the repository is on lyra.org, to
> which only Greg Stein would have telnet access. Instead, I could
> disable all mail delivery for xml-checkins subscribers before moving
> things around, so that people don't get buried in a mass of CVS
> messages, and then enable mail delivery again.
Ah, good idea!
I wasn't advocating reaching into the CVS repo like that. it's just
a lot easier (& faster) that way. ;-} Definately not the way to go
about it.
-Fred
--
Fred L. Drake, Jr.
Corporation for National Research Initiatives
From Mike.Olson@FourThought.com Thu Jul 29 10:07:46 1999
From: Mike.Olson@FourThought.com (Mike Olson)
Date: Thu, 29 Jul 1999 04:07:46 -0500
Subject: [XML-SIG] Python DOM Unification -- level
References: <3724CC49.AAB857A5@prescod.net>
<14116.55422.189139.235663@amarok.cnri.reston.va.us>
<3724E2A1.62223458@prescod.net> <14117.52230.551462.836651@weyr.cnri.reston.va.us>
Message-ID: <37A019E2.B334709D@FourThought.com>
This is a cryptographically signed message in MIME format.
--------------ms2480E40C541356542D33EE3F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hey everyone
Sorry we at Fourthought have been kinda slow keeping up wth this list and
4DOM and such. We had to pick up an extra contract to pay for the python
conferences ;)
We're gonna have some free time in August to do some major work on 4DOM and
4XSLT, including getting 4XSLT up to date with the latest XSLT draft and
breaking out the patterns into 4XPath (or some clever name).
I wanted to bring up the DOM interface unification topic again as we will be
working on 4DOM this month and may have time to experiment with some Lit/ python
interfaces. Last we left off, we couldn't decide how many and how lit the
interfaces should be. Is anyone still doing work to come up with a unified
interface(s)? Is it something we still want to consider? Should we
(Fourthought) just produce a lit interface as pythonic as possible and then
mold/wrap pydom and 4dom to meet it?
For my 2 cents worth, I guess I see a need for 2 interfaces. The one
defined by W3C and a totally pythonic interface. Then a wrapper that can be
used to turn a DOM compliant interface implementation into the pythonic
interface. ORB/ORBless I think we decided is orthagonal to this decision.
Mike
"Fred L. Drake" wrote:
> Paul Prescod writes:
> > Shouldn't the exception objects and class constants be shared between DOM
> > implementations?
>
> Absolutely!
>
> > Why do Node, NodeList and NamedNodeMap have to be top-level. Does it make
> > sense for clients to construct them?
>
> No, but you knew that before I did. ;-)
>
> -Fred
>
> --
> Fred L. Drake, Jr.
> Corporation for National Research Initiatives
>
> _______________________________________________
> XML-SIG maillist - XML-SIG@python.org
> http://www.python.org/mailman/listinfo/xml-sig
--
----------------
Mike Olson
Consulting Member
FourThought LLC
http://www.fourthought.com http://opentechnology.org
--------------ms2480E40C541356542D33EE3F
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIKpgYJKoZIhvcNAQcCoIIKlzCCCpMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
CDIwggT8MIIEZaADAgECAhBgV5Y2xbIHJpkIwhs+UflwMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDUwNjAwMDAw
MFoXDTAwMDUwNTIzNTk1OVowggEXMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCk1pa2UgT2xzb24xKTAnBgkqhkiG9w0B
CQEWGm1pa2Uub2xzb25AZm91cnRob3VnaHQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCuk+Frgbi1QG7ni53t3TaFTU5IXKp/aOYYXaR/iPN9Ure9P6fAajZIDUXyR+bCIe8U
Sq1kHjMNbb/ziX3/oPPeUy3Cy1sVZ/Cq2FPofSInSaLl0EB+k0aMbEBtmyVxTGByoNaPL3Lj
Er/aLaIkNcPIaCzT0okEOA/pu9RU0efBaQIDAQABo4IBjzCCAYswCQYDVR0TBAIwADCBrAYD
VR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEa
PVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcg
VmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2
M2YyMDQ3MDI5Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0
N2RhNWQzZjIxNDFiZWFkYjJiZDJlODkyMTNhZTZhZjlkZjExNDk5OWEzYjg0NWY5ZjNlYTQ1
MGMwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy
bDANBgkqhkiG9w0BAQQFAAOBgQB8SeBjPc9TSSC1iwIP0gVMzQVGkcPG4I/yoMUFK1CfgW6T
dvtP5z9WNcSIfQ8mIjsl/jbwnfYevfK0EiCjU5slnsOjrbIiWwRe7qYBuGqE6gnfkhMRt8l3
ZJe2AqRptWZYY8axL5nQm0iSnVEmYoZAtAnQkkldheTU4n+x9vlUHjCCAy4wggKXoAMCAQIC
EQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTla
MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv
cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD
QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBo
u5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+H
Sr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglg
hkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIB
Fh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPK
ZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjj
F7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCC
AjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln
biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv
UlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBD
bGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQC
EGBXljbFsgcmmQjCGz5R+XAwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw05OTA3MjkwOTA3NDZaMCMGCSqGSIb3DQEJBDEWBBSePVP7
dR9gzCulzpKiUZsSXTLrLDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3
DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG
9w0BAQEFAASBgBe6nridNX25zEuWr0G5OjfARXPu36Nx6K/8q2yTSL1u0jJfsL5tGAZOq5Ad
NrlJfSexqF/JjHyKiuTm4SRDCynGZW/I2k6kV2mtIC2I9UUXdS3knVLJQC1zG2ZeHnMnl0Lj
JVvPbFmbGtT+Cf9Os0HMGIGVe8pQHJf0xBrc6cWk
--------------ms2480E40C541356542D33EE3F--