usfm-grammar-web 3.2.0 → 3.2.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -3,6 +3,8 @@
3
3
  ## Description
4
4
  This is the web alternative to the (USFM-Grammar 3.x)[https://www.npmjs.com/package/usfm-grammar] library to be used from HTML, react etc. USFM Grammar is a JavaScript library for parsing and converting USFM (Unified Standard Format Markers) to/from USJ (Unified Standard JSON) format. This library provides functionalities to parse USFM strings into a syntax tree and convert them into a JSON-like structure (USJ), and vice versa.
5
5
 
6
+ > :information_source: For Node.js, use the [usfm-grammar](https://www.npmjs.com/package/usfm-grammar) package; `usfm-grammar-web` is for browsers and bundlers.
7
+
6
8
  ## Installation
7
9
  You can install USFM Grammar via npm:
8
10
 
@@ -23,10 +25,10 @@ function App() {
23
25
 
24
26
  useEffect(() => {
25
27
  const initParser = async () => {
26
- await USFMParser.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter-usfm.wasm",
27
- "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter.wasm");
28
- await Validator.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter-usfm.wasm",
29
- "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter.wasm");
28
+ await USFMParser.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/tree-sitter-usfm.wasm",
29
+ "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/web-tree-sitter.wasm");
30
+ await Validator.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/tree-sitter-usfm.wasm",
31
+ "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/web-tree-sitter.wasm");
30
32
 
31
33
  };
32
34
  initParser();
@@ -60,13 +62,13 @@ It can be used directly in the HTML script tag too. Please ensure its dependenci
60
62
 
61
63
  ```html
62
64
  <script type="module">
63
- import { USFMParser, Filter, Validator } from 'https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/dist/bundle.mjs';
65
+ import { USFMParser, Filter, Validator } from 'https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/dist/bundle.mjs';
64
66
  console.log('Hello world');
65
67
  (async () => {
66
- await USFMParser.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter-usfm.wasm",
67
- "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter.wasm");
68
- await Validator.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter-usfm.wasm",
69
- "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.0/tree-sitter.wasm");
68
+ await USFMParser.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/tree-sitter-usfm.wasm",
69
+ "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/web-tree-sitter.wasm");
70
+ await Validator.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/tree-sitter-usfm.wasm",
71
+ "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/web-tree-sitter.wasm");
70
72
  const usfmParser = new USFMParser('\\id GEN\n\\c 1\n\\p\n\\v 1 In the begining..\\v 2 more text')
71
73
  const output = usfmParser.toUSJ()
72
74
  console.log({ output })
@@ -109,7 +111,7 @@ Working with USJ, also gives options like filtering selected markers, to edit th
109
111
 
110
112
  To work with the XML format, USX:
111
113
  ```javascript
112
- import { DOMImplementation, XMLSerializer } from 'xmldom';
114
+ import { DOMParser, XMLSerializer } from '@xmldom/xmldom';
113
115
 
114
116
  const USFM = '\\id GEN\n\\c 1\n\\p\n\\v 1 In the begining..\\v 2 some more text'
115
117
  const usfmParser = new USFMParser(USFM);
@@ -123,6 +125,11 @@ console.log(usx);
123
125
  const usfmParser2 = new USFMParser(null, null, usxElem) // USX to USFM
124
126
  const usfmGen = usfmParser2.usfm;
125
127
  console.log(usfmGen);
128
+
129
+ // USX from a string e.g. uploaded file contents
130
+ const usxText = '<usx version="3.1"><book code="GEN" style="id"/><chapter number="1" style="c"/><para style="p"><verse number="1" style="v"/>In the beginning...</para></usx>';
131
+ const usxDoc = new DOMParser().parseFromString(usxText.replace(/^/, ''), 'text/xml'); // strip BOM, if any
132
+ const usfmParser3 = new USFMParser(null, null, usxDoc.documentElement);
126
133
  ```
127
134
  ### BibleNLP format
128
135
  Bible NLP format consists of two `txt` files: the first, with verse texts, one per line and the second, with corresponding references. The API generates a JSON with two fields, `text` and `vref`, each containing an array of strings.
@@ -197,9 +204,9 @@ const simpleUSJ = {
197
204
  { type: 'book', marker: 'id', code: 'GEN', content: [] },
198
205
  { type: 'chapter', marker: 'c', number: '1', sid: 'GEN 1' },
199
206
  { type: 'para', marker: 'p', content: [
200
- {type: 'verse', marker: 'v', number: 1 },
207
+ {type: 'verse', marker: 'v', number: '1' },
201
208
  "In the begining..",
202
- {type: 'verse', marker: 'v', number: 2 }
209
+ {type: 'verse', marker: 'v', number: '2' }
203
210
  ] }
204
211
  ]
205
212
  }
@@ -222,7 +229,7 @@ The filtering on USJ, the JSON output, is a feature incorporated to allow data e
222
229
 
223
230
  - *combineTexts*
224
231
 
225
- Fourth input parameter to `toUSJ()` and `toList` of `USFMParser` class. Defaults to `true`. After filtering out makers like paragraphs and characters, we are left with texts from within them, if 'text-in-excluded-parent' is also not excluded. These text snippets may come as separate components in the contents list. When this option is `True`, the consequetive text snippets will be concatinated together. The text concatination is done in a puctuation and space aware manner. If users need more control over the space handling or for any other reason, would prefer the texts snippets as different components in the output, this can be set to `False`.
232
+ Fourth input parameter to `toUSJ()` and `toList` of `USFMParser` class. Defaults to `true`. After filtering out makers like paragraphs and characters, we are left with texts from within them, if 'text-in-excluded-parent' is also not excluded. These text snippets may come as separate components in the contents list. When this option is `True`, the consequetive text snippets will be concatenated together. The text concatenation is done in a puctuation and space aware manner. If users need more control over the space handling or for any other reason, would prefer the texts snippets as different components in the output, this can be set to `False`.
226
233
 
227
234
  - *usfm_grammar.Filter*
228
235
 
@@ -234,11 +241,13 @@ The filtering on USJ, the JSON output, is a feature incorporated to allow data e
234
241
  PARAGRAPHS : paragraph markers like \p, poetry markers, list table markers
235
242
  CHARACTERS : all character level markups like \em, \w, \wj etc and their nested versions with +
236
243
  NOTES : foot note, cross-reference and their content markers
244
+ LISTS : list markers like \li, \lh, \lim and the \list-s/\list-e milestones
237
245
  STUDY_BIBLE : \esb and \cat
238
246
  BCV : \id, \c and \v
239
- TEXT : 'text-in-excluded-parent'
247
+ TEXT : 'text-in-excluded-parent' and 'text'
248
+ ZNAMESPACES : all user-extended \z markers, as one group
240
249
  ```
241
- To inspect which are the markers in each of these options, it could be just printed out, `print(Filter.TITLES)`. These could be used individually or concatinated to get the desired filtering of markers and data:
250
+ To inspect which are the markers in each of these options, it could be just printed out, `console.log(Filter.TITLES)`. These could be used individually or concatenated to get the desired filtering of markers and data:
242
251
  ```javascript
243
252
  output = usfmParser.toUSJ(null, Filter.BCV) //to include
244
253
  output = usfmParser.toUSJ(null, [...Filter.BCV, ...Filter.TEXT]) //to include
@@ -254,6 +263,146 @@ The filtering on USJ, the JSON output, is a feature incorporated to allow data e
254
263
 
255
264
 
256
265
 
266
+ ### User-extended markers (\z)
267
+
268
+ The USFM spec reserves markers beginning with `\z` for [user-defined extensions](https://docs.usfm.bible/usfm/3.1.2/extensions.html). usfm-grammar parses these, and represents them in USJ and USX using the type the extension belongs to. A `markers.ext` file can be supplied to declare which markers exist and what each one is, so that the output is what you expect. Without it, the type is guessed from how the marker is written.
269
+
270
+ - *Supplying a markers.ext*
271
+
272
+ `markersExt`, the sixth argument to the `USFMParser` constructor, takes the **contents** of the file, not its path. Supply it when parsing USFM; it is not needed, and should not be passed, when converting from USJ or USX.
273
+ ```javascript
274
+ import {USFMParser, Filter} from 'usfm-grammar-web';
275
+
276
+ await USFMParser.init("https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/tree-sitter-usfm.wasm",
277
+ "https://cdn.jsdelivr.net/npm/usfm-grammar-web@3.2.2/web-tree-sitter.wasm");
278
+
279
+ const myParser = new USFMParser(inputUsfm, null, null, null, null, markersExt);
280
+ const output = myParser.toUSJ();
281
+ ```
282
+
283
+ - *The markers.ext file*
284
+
285
+ A plain text file, in a USFM-like syntax, with one block per extension marker. Blank lines separate the blocks.
286
+ ```
287
+ \marker zheading
288
+ \category title
289
+ \description A custom section heading.
290
+
291
+ \marker zbadge
292
+ \category char
293
+ \description A custom character marker.
294
+
295
+ \marker zalign-s
296
+ \category milestone
297
+ \description A custom alignment milestone.
298
+
299
+ \marker znote
300
+ \category footnote
301
+ \description A custom note marker.
302
+ ```
303
+ `\marker` and `\category` are the two fields that matter. `\description`, and any other field, is read but does not affect parsing. Only markers starting with `z` are accepted; a block declaring anything else is ignored.
304
+
305
+ - *Categories and the four major types*
306
+
307
+ `\category` must be one of the values below. Each maps onto one of four major types, and that major type is what decides how the marker is parsed and what it becomes in the output.
308
+
309
+ | Major type | `\category` values | USJ `type` | USX element |
310
+ | --- | --- | --- | --- |
311
+ | para | `para`, `header`, `title`, `introduction`, `section`, `versepara`, `list`, `otherpara` | `para` | `<para>` |
312
+ | char | `char`, `introchar`, `listchar`, `footnotechar`, `crossreferencechar` | `char` | `<char>` |
313
+ | note | `note`, `footnote`, `crossreference` | `note` | `<note>` |
314
+ | milestone | `milestone` | `ms` | `<ms>` |
315
+
316
+ A `\category` outside this list, or a block with no `\category` at all, raises an error.
317
+
318
+ :warning: Only the major type is used. The minor type, and the rules the spec attaches to it about where such a marker may occur, are not enforced — a declared extension marker is accepted anywhere in the document. So declaring `\category title` rather than `\category para` changes nothing about the output; both produce a `para`. In particular, a `versepara` extension is not treated as verse text: its content is not attributed to the preceding verse (e.g. for `vid` on continuation paragraphs or the BibleNLP/list outputs and filtered USJs).
319
+
320
+ - *Expected syntax per major type*
321
+
322
+ Each major type has to be written the way the corresponding standard markers are written, otherwise parsing fails.
323
+ ```
324
+ para \zheading A line of its own
325
+ char \zbadge inline content\zbadge* (closing marker required)
326
+ milestone \zalign-s\* or \zalign-s|x-strong="G25320"\*
327
+ note \znote + \zbadge note body\zbadge*\znote*
328
+ ```
329
+ A note takes a caller as its first token, exactly like `\f` and `\x` do. Its body must be made of extension markers; plain text directly inside a note is not accepted.
330
+
331
+ - *What may appear inside an extension marker*
332
+
333
+ Within a user-extended marker, only other user-extended markers (`\z...`, or `\+z...` when nested) and custom attributes (`x-...`) are allowed. Markers from the common pool are not. So this parses:
334
+ ```
335
+ \zbadge outer \+zbadge nested\+zbadge* text\zbadge*
336
+ \zbadge content|x-key="value"\zbadge*
337
+ ```
338
+ and these are parsing errors:
339
+ ```
340
+ \zbadge outer \nd Lord\nd* text\zbadge*
341
+ \zbadge content|lemma="value"\zbadge*
342
+ \c 1
343
+ \zheading A line \v 1 verse text
344
+ ```
345
+ A verse cannot be part of a custom para either. A `\v` ends the custom para. When the custom para sits within a verse para such as `\p`, the verse continues in that enclosing para; otherwise, as in the last example, it is a parsing error.
346
+
347
+ - *When no markers.ext is given*
348
+
349
+ The markers are still parsed, and the type is inferred from the syntax alone. A warning is recorded for each one, listing the node and suggesting that a markers.ext be supplied.
350
+ ```
351
+ \zheading A line of its own -> para (no closing marker)
352
+ \zbadge inline\zbadge* -> char (closed with its own marker)
353
+ \zalign-s\* -> ms (closed with \*)
354
+ ```
355
+ :warning: Notes cannot be told apart from character markers this way, since both are written as an opening marker closed by its own marker. An undeclared note-like marker is reported as `char`. Declare it in a markers.ext if you need it to come out as a `note`.
356
+
357
+ - *Filtering extension markers*
358
+
359
+ All `\z` markers are filtered as a single group, named `user-extension`, rather than one marker at a time. See the `ZNAMESPACES` option in [Filtering on USJ](#filtering-on-usj).
360
+
361
+ - *A worked example*
362
+
363
+ With this `markers.ext`
364
+ ```
365
+ \marker zheading
366
+ \category title
367
+ \description A custom section heading.
368
+
369
+ \marker zbadge
370
+ \category char
371
+ \description A custom character marker.
372
+
373
+ \marker zalign-s
374
+ \category milestone
375
+ \description A custom alignment milestone.
376
+ ```
377
+ this USFM
378
+ ```
379
+ \id GEN
380
+ \c 1
381
+ \p
382
+ \v 1 Text with \zbadge inline content\zbadge* and more.
383
+ \zheading A line of its own
384
+ \v 2 Aligned \zalign-s|x-strong="G25320"\* text.
385
+ ```
386
+ gives these USJ nodes
387
+ ```json
388
+ {"type": "char", "content": [" inline content"], "marker": "zbadge"}
389
+ {"type": "para", "content": [" A line of its own\n"], "marker": "zheading"}
390
+ {"type": "ms", "content": [], "marker": "zalign-s", "x-strong": "G25320"}
391
+ ```
392
+ and this USX
393
+ ```xml
394
+ <usx version="3.1.2">
395
+ <book code="GEN" style="id"/>
396
+ <chapter number="1" style="c" sid="GEN 1"/>
397
+ <para style="p"><verse number="1" style="v" sid="GEN 1:1"/>Text with <char style="zbadge"> inline content</char> and more.
398
+ <para style="zheading"> A line of its own
399
+ </para><verse eid="GEN 1:1"/><verse number="2" style="v" sid="GEN 1:2"/>Aligned <ms style="zalign-s" x-strong="G25320"/> text.
400
+ <verse eid="GEN 1:2"/></para>
401
+ <chapter eid="GEN 1"/>
402
+ </usx>
403
+ ```
404
+
405
+
257
406
  ## Contributing
258
407
  Contributions are welcome! If you find any issues or have suggestions for improvements, feel free to open an issue or create a pull request on [GitHub](https://github.com/Bridgeconn/usfm-grammar).
259
408