1AnyData::Format::XML(3)User Contributed Perl DocumentatioAnnyData::Format::XML(3)
2
3
4

NAME

6        AnyData::Format::XML - tiedhash and DBI access to XML
7

SYNOPSIS

9        # access XML data via a multi-dimensional tied hash
10        # see AnyData.pod for full details
11        #
12        use AnyData;
13        my $table = adTie( 'XML', $file, $mode, $flags );
14
15        OR
16
17        # convert data to and from XML
18        # see AnyData.pod for full details
19        #
20        use AnyData;
21        adConvert( 'XML', $file1, $any_other_format, $file2, $flags );
22        adConvert( $any_other_format, $file1, 'XML', $file2, $flags );
23
24        OR
25
26        # access the data via DBI and SQL
27        # see DBD::AnyData.pod for full details
28        #
29        use DBI;
30        my $dbh = DBI->connect( 'dbi:AnyData' );
31        $dbh->func('mytable','XML',$file,$flags,'ad_catalog');
32
33       See below for a description of the optional flags that apply to all of
34       these examples.
35

DESCRIPTION

37       This module allows you to create, search, modify and/or convert XML
38       data and files by treating them as databases without having to actually
39       create separate database files.  The data can be accessed via a multi-
40       dimensional tiedhash using AnyData.pm or via DBI and SQL commands using
41       DBD::AnyData.pm.  See those modules for complete details of usage.
42
43       The module is built on top of Michel Rodriguez's excellent XML::Twig
44       which means that the AnyData interfaces can now include information
45       from DTDs, be smarter about inferring data structure, reduce memory
46       consumption on huge files, and provide access to many powerful features
47       of XML::Twig and XML::Parser on which it is based.
48
49       Importing options allow you to import/access/modify XML of almost any
50       length or complexity.  This includes the ability to access different
51       subtrees as separate or joined databases.
52
53       Exporting and converting options allow you to take data from almost any
54       source (a perl array, any DBI database, etc.) and output it as an XML
55       file.  You can control the formating of the resulting XML either by
56       supplying a DTD listing things like nesting of tags and which columns
57       should be output as attributes and/or you can use XML::Twig
58       pretty_print settings to generate half a dozen different levels of com‐
59       pactness or whitespace in how the XML looks.
60
61       The documentaion below outlines the special flags that can be used in
62       either of the interfaces to fine-tune how the XML is treated.
63
64       The flags listed below define the relationship between tags and
65       attributes in the XML document and columns in the resulting database.
66       In many cases, you can simply accept the defaults and the database will
67       be built automatically.  However, you can also fine tune the generation
68       of the database by specifying which tags and attributes you are inter‐
69       ested in and their relationship with database columns.
70

USAGE

72       Prerequisites
73
74       To use the tied hash interface, you will need
75
76        AnyData
77        XML::Twig
78        XML::Parser
79
80       To use the DBI/SQL interface, you will need those, and also
81
82        DBI
83        DBD::AnyData
84
85       Required flags ( none )
86
87       If no flags are specified, then the module determines the database
88       structure from examining the file or data itself, making use of the DTD
89       if there is one, otherwise scanning the first child of the XML tree for
90       structural information.
91
92       Optional flags
93
94        If the default behavior is not sufficient, you may either specify a
95        "record_tag" which will be used to define column names, or you can define an
96        entire tag-to-column mapping.
97
98       For simple XML, no flags are necessary:
99
100        <table>
101           <row row_id="1"><name>Joe</name><location>Seattle</location></row>
102           <row row_id="2"><name>Sue</name><location>Portland</location></row>
103        </table>
104
105       The record_tag will default to the first child, namely "row".  The col‐
106       umn names will be generated from the attributes of the record tag and
107       all of the tags included under the record tag, so the column names in
108       this example will be "row_id","name","location".
109
110       If the record_tag is not the first child, you will need to specify it.
111       For example:
112
113        <db>
114          <table table_id="1">
115            <row row_id="1"><name>Joe</name><location>Seattle</location></row>
116            <row row_id="2"><name>Sue</name><location>Portland</location></row>
117          </table>
118          <table table_id="2">
119            <row row_id="1"><name>Bob</name><location>Boise</location></row>
120            <row row_id="2"><name>Bev</name><location>Billings</location></row>
121          </table>
122        </db>
123
124       In this case you will need to specify "row" as the record_tag since it
125       is not the first child of the tree.  The column names will be generated
126       from the attributes of row's parent (if the parent is not the root),
127       from row's attributes and sub tags, i.e. "ta‐
128       ble_id","row_id","name","location".
129
130       In some cases you will need to specify an entire tag-to-column mapping.
131       For example, if you want to use a different name for the database col‐
132       umn than is used in the XML (especially if the XML tag is not a valid
133       SQL column name).  You'd also need to specify a mapping if there are
134       two tags with the same name in different places in the XML tree.
135
136       The column mapping is a reference to an array of column definitions.  A
137       column definition is either a simple name of a tag, or a hash reference
138       with the key containing the full path of the XML tag and the value con‐
139       taining the desired column name alias.
140
141       For example:
142
143         col_map => [ 'part_id', 'part_name', 'availability' ];
144
145       That will find the first three tags with those names and create the
146       database using the same names for the tags.
147
148       Or:
149
150         col_map => [
151                      { '/parts/shop/id'        => 'shop_id'},
152                      { '/parts/shop/part/id'   => 'part_id'},
153                      { '/parts/shop/part/name' => 'part_name'},
154                    ];
155
156       That would find the three tags referenced on the left and create a
157       database with the three column names referenced on the right.
158
159       When exporting XML, you can specify a DTD to control the output.  For
160       example, if you import a table from CSV or from an Array, you can out‐
161       put as XML and specify which of the columns become tags and which
162       become attributes and also specify the nesting of the tags in your DTD.
163
164       The XML format parser is built on top of Michel Rodriguez's excellent
165       XML::Twig which is itslef based on XML::Parser.  Parameters to either
166       of those modules may be passed in the flags for adTie() and the other
167       commands including the "prettyPrint" flag to specify how the output XML
168       is displayed and things like ProtocolEncoding.  ProtocolEncoding
169       defaults to 'ISO-8859-1', all other flags keep the defaults of
170       XML::Twig and XML::Parser.  See the documentation of those modules for
171       details;
172
173        CAUTION: Unlike other formats, the XML format does not save changes to
174        the file as they are entered, but only saves the changes when you explicitly
175        request them to be saved with the adExport() command.
176
178       copyright 2000, Jeff Zucker <jeff@vpservices.com> all rights reserved
179
180
181
182perl v5.8.8                       2001-07-17           AnyData::Format::XML(3)
Impressum