source: trip-planner-front/node_modules/@trysound/sax/README.md@ e29cc2e

Last change on this file since e29cc2e was 6a3a178, checked in by Ema <ema_spirova@…>, 3 years ago

initial commit

  • Property mode set to 100644
File size: 7.6 KB
RevLine 
[6a3a178]1# svg/sax
2
3A maintained fork of [sax-js](https://github.com/isaacs/sax-js) sax-style parser for XML and HTML.
4
5Designed with [node](http://nodejs.org/) in mind, but should work fine in
6the browser or other CommonJS implementations.
7
8## What This Is
9
10* A very simple tool to parse through an XML string.
11* A stepping stone to a streaming HTML parser.
12* A handy way to deal with RSS and other mostly-ok-but-kinda-broken XML
13 docs.
14
15## What This Is (probably) Not
16
17* An HTML Parser - That's a fine goal, but this isn't it. It's just
18 XML.
19* A DOM Builder - You can use it to build an object model out of XML,
20 but it doesn't do that out of the box.
21* XSLT - No DOM = no querying.
22* 100% Compliant with (some other SAX implementation) - Most SAX
23 implementations are in Java and do a lot more than this does.
24* An XML Validator - It does a little validation when in strict mode, but
25 not much.
26* A Schema-Aware XSD Thing - Schemas are an exercise in fetishistic
27 masochism.
28* A DTD-aware Thing - Fetching DTDs is a much bigger job.
29
30## Regarding `<!DOCTYPE`s and `<!ENTITY`s
31
32The parser will handle the basic XML entities in text nodes and attribute
33values: `&amp; &lt; &gt; &apos; &quot;`. It's possible to define additional
34entities in XML by putting them in the DTD. This parser doesn't do anything
35with that. If you want to listen to the `ondoctype` event, and then fetch
36the doctypes, and read the entities and add them to `parser.ENTITIES`, then
37be my guest.
38
39Unknown entities will fail in strict mode, and in loose mode, will pass
40through unmolested.
41
42## Usage
43
44```javascript
45var sax = require("./lib/sax"),
46 strict = true, // set to false for html-mode
47 parser = sax.parser(strict);
48
49parser.onerror = function (e) {
50 // an error happened.
51};
52parser.ontext = function (t) {
53 // got some text. t is the string of text.
54};
55parser.onopentag = function (node) {
56 // opened a tag. node has "name" and "attributes"
57};
58parser.onattribute = function (attr) {
59 // an attribute. attr has "name" and "value"
60};
61parser.onend = function () {
62 // parser stream is done, and ready to have more stuff written to it.
63};
64
65parser.write('<xml>Hello, <who name="world">world</who>!</xml>').close();
66```
67
68
69## Arguments
70
71Pass the following arguments to the parser function. All are optional.
72
73`strict` - Boolean. Whether or not to be a jerk. Default: `false`.
74
75`opt` - Object bag of settings regarding string formatting. All default to `false`.
76
77Settings supported:
78
79* `trim` - Boolean. Whether or not to trim text and comment nodes.
80* `normalize` - Boolean. If true, then turn any whitespace into a single
81 space.
82* `lowercase` - Boolean. If true, then lowercase tag names and attribute names
83 in loose mode, rather than uppercasing them.
84* `xmlns` - Boolean. If true, then namespaces are supported.
85* `position` - Boolean. If false, then don't track line/col/position.
86* `strictEntities` - Boolean. If true, only parse [predefined XML
87 entities](http://www.w3.org/TR/REC-xml/#sec-predefined-ent)
88 (`&amp;`, `&apos;`, `&gt;`, `&lt;`, and `&quot;`)
89
90## Methods
91
92`write` - Write bytes onto the stream. You don't have to do this all at
93once. You can keep writing as much as you want.
94
95`close` - Close the stream. Once closed, no more data may be written until
96it is done processing the buffer, which is signaled by the `end` event.
97
98`resume` - To gracefully handle errors, assign a listener to the `error`
99event. Then, when the error is taken care of, you can call `resume` to
100continue parsing. Otherwise, the parser will not continue while in an error
101state.
102
103## Members
104
105At all times, the parser object will have the following members:
106
107`line`, `column`, `position` - Indications of the position in the XML
108document where the parser currently is looking.
109
110`startTagPosition` - Indicates the position where the current tag starts.
111
112`closed` - Boolean indicating whether or not the parser can be written to.
113If it's `true`, then wait for the `ready` event to write again.
114
115`strict` - Boolean indicating whether or not the parser is a jerk.
116
117`opt` - Any options passed into the constructor.
118
119`tag` - The current tag being dealt with.
120
121And a bunch of other stuff that you probably shouldn't touch.
122
123## Events
124
125All events emit with a single argument. To listen to an event, assign a
126function to `on<eventname>`. Functions get executed in the this-context of
127the parser object. The list of supported events are also in the exported
128`EVENTS` array.
129
130`error` - Indication that something bad happened. The error will be hanging
131out on `parser.error`, and must be deleted before parsing can continue. By
132listening to this event, you can keep an eye on that kind of stuff. Note:
133this happens *much* more in strict mode. Argument: instance of `Error`.
134
135`text` - Text node. Argument: string of text.
136
137`doctype` - The `<!DOCTYPE` declaration. Argument: doctype string.
138
139`processinginstruction` - Stuff like `<?xml foo="blerg" ?>`. Argument:
140object with `name` and `body` members. Attributes are not parsed, as
141processing instructions have implementation dependent semantics.
142
143`sgmldeclaration` - Random SGML declarations. Stuff like `<!ENTITY p>`
144would trigger this kind of event. This is a weird thing to support, so it
145might go away at some point. SAX isn't intended to be used to parse SGML,
146after all.
147
148`opentagstart` - Emitted immediately when the tag name is available,
149but before any attributes are encountered. Argument: object with a
150`name` field and an empty `attributes` set. Note that this is the
151same object that will later be emitted in the `opentag` event.
152
153`opentag` - An opening tag. Argument: object with `name` and `attributes`.
154In non-strict mode, tag names are uppercased, unless the `lowercase`
155option is set. If the `xmlns` option is set, then it will contain
156namespace binding information on the `ns` member, and will have a
157`local`, `prefix`, and `uri` member.
158
159`closetag` - A closing tag. In loose mode, tags are auto-closed if their
160parent closes. In strict mode, well-formedness is enforced. Note that
161self-closing tags will have `closeTag` emitted immediately after `openTag`.
162Argument: tag name.
163
164`attribute` - An attribute node. Argument: object with `name` and `value`.
165In non-strict mode, attribute names are uppercased, unless the `lowercase`
166option is set. If the `xmlns` option is set, it will also contains namespace
167information.
168
169`comment` - A comment node. Argument: the string of the comment.
170
171`opencdata` - The opening tag of a `<![CDATA[` block.
172
173`cdata` - The text of a `<![CDATA[` block. Since `<![CDATA[` blocks can get
174quite large, this event may fire multiple times for a single block, if it
175is broken up into multiple `write()`s. Argument: the string of random
176character data.
177
178`closecdata` - The closing tag (`]]>`) of a `<![CDATA[` block.
179
180`opennamespace` - If the `xmlns` option is set, then this event will
181signal the start of a new namespace binding.
182
183`closenamespace` - If the `xmlns` option is set, then this event will
184signal the end of a namespace binding.
185
186`end` - Indication that the closed stream has ended.
187
188`ready` - Indication that the stream has reset, and is ready to be written
189to.
190
191`noscript` - In non-strict mode, `<script>` tags trigger a `"script"`
192event, and their contents are not checked for special xml characters.
193If you pass `noscript: true`, then this behavior is suppressed.
194
195## Reporting Problems
196
197It's best to write a failing test if you find an issue. I will always
198accept pull requests with failing tests if they demonstrate intended
199behavior, but it is very hard to figure out what issue you're describing
200without a test. Writing a test is also the best way for you yourself
201to figure out if you really understand the issue you think you have with
202sax-js.
Note: See TracBrowser for help on using the repository browser.