X-Git-Url: https://git.ladys.computer/Shushe/blobdiff_plain/1c02c25ab49b46225f48d51ccc52648c20c82eaf..90810b4c234960e725e770f331b13c4687f407c8:/README.markdown?ds=sidebyside diff --git a/README.markdown b/README.markdown index 4c1f1d6..4427c7f 100644 --- a/README.markdown +++ b/README.markdown @@ -255,8 +255,10 @@ For example, the trivial `text/plain` parser is defined as follows :⁠— + <书社:id>example:text/plain @@ -271,8 +273,21 @@ Alternatively, you can set the `@书社:supported-media-types` attribute on the root element of the parser to override media type support detection. -Parsers can also target specific dialects of X·M·L, in which case they - operate on the same basic principles as transforms (described below). +Even when `@书社:supported-media-types` is set, it is a requirement + that each parser transform any `` elements with a + `@type` which matches their registered types into something else. +Otherwise the parser will be stuck in an endless loop. +The result tree of applying the transform to the `` + element will be reparsed (in case any new `` elements + were added in its subtree), and a `@书社:parsed-by` attribute will be + added to each toplevel element in the result. +The value of this attribute will be the value of the `<书社:id>` + toplevel element in the parser. + +It is possible for parsers to support zero plaintext types. +This is useful when targeting specific dialects of X·M·L; parsers in + this sense operate on the same basic principles as transforms + (described below). The major distinction between X·M·L parsers and transforms is where in the process the transformation happens: Parsers are applied *prior* to embedding (and can be used to generate