Commit 182301ce authored by gerd's avatar gerd

fixes in documentation, also in ocamldoc


git-svn-id: https://godirepo.camlcity.org/svn/lib-pxp/trunk@747 dbe99aee-44db-0310-b2b3-d33182c8eb97
parent 2ca46477
neue Klasse fake_system. Wenn der untergeordnete resolver
funktioniert, wird xid_system auf eine bestimmte URL gesetzt.
???
- Pxp_document: Add hooks that can be set by the user for:
* post_add
* pre_delete
This would be useful for automatically maintaining an index
of elements (by name), if this is required.
- Warners: Polymorphic variants benutzen.
Cannot_represent auch als Fehler! (A. Frisch)
DONE
- Pxp_dtd: Add class type for dtd
- Doku: Sektion "Known problems"
* Non-representable characters. Kann zu well-formedness errors fhren.
- Finish pxp_xpath. Add support in preprocessor for XPath expressions.
- Check:
Pxp_lexers: Thread-safe? Reentrant?
DONE
- Unicode:
Include Characters > 0xFFFF
DONE
- Lexers:
einchecken, DONE
wlex-Support DONE
- Ausgabe von XML verbessern:
* derived DTDs richtig ausgeben knnen
schwierig, man muss ein extdecl vergleichbares Flag hinzunehmen,
dass true ist, wenn per SYSTEM/PUBLIC in ein external entity
verzweigt wird
Optionale ?domain-Attribute. Gltige domains:
- Ext_subset: im SYSTEM/PUBLIC-Entity oder in einem
von dort angesteuerten Entity
- Int_subset: Direkt im internal subset definiert
- Ext_ent_of_int_subset: In einem externen Entity, das
in das internal subset inkludiert wird.
Default ist Int_subset.
Frage: (1) Zhlt nur der Ort der Deklaration, oder auch, wo
das deklarierende Entity angezogen wird?
(2) Kann man extdecl-Flags auf domains reduzieren?
NICHT IN 1.2. Das ist viel zu schwierig. Eher in die Richtung entwickeln,
den internal subset orignalgetreu wiederzugeben (z.B. indem man den
Token-Strom aufzeichnet). Das ist allerdings nur fr geparste DTDs
sinnvoll; was machen wir mit selbsterzeugten DTDs und modifizierten
DTDs?
* Optionen: Elemente ausgegeben ja/nein usw.
???
* event-based parser: Entities NICHT auflsen
NICHT IN 1.2
- Auch bei parse_wfdocument_entity die DTD transformieren knnen
DONE
- resolver: externe entities nicht parsen (durch "" ersetzen)
NICHT NOTWENDIG. Kann durch Pxp_reader auf einfache Weise bereitgestellt
werden.
- from_string ~alt
DONE
- Wirkung von `Extend_dtd_fully auch bei parse_wfdocument_entity ???
Geht wohl nicht.
- ocamlnet-channels untersttzen, sowohl bei input-channels als
auch output
DONE
- Doku:
- Wann ist dtd#root gesetzt?
- Wann ist dtd#id gesetzt?
DONE
- Event-based parsers:
* Parse a single element, PI, comment, ... instead of misc* element misc*
DONE
* process_entity: erstes Token kann bergeben werden DONE
Letztes Token? DONE
Problem: m2parsergen erzwingt, dass immer ein Token zuviel gelesen
wird. Mgliche Lsung: Eine Grammatikregel wird mit ! markiert;
diese liest dann nicht ein weiteres Token. Nur erlaubt bei Regeln,
die auf ein Token enden. Dies erfordert auch eine nderung des
Aufrufs.
Problem: Um process_expr zu benutzen, muss man low-level entity
Methoden aufrufen. Eine bessere API finden.
* { and } inside attribute lists DONE
TODO: Don't forget: pxp_lex_content_string.src: more efficient way of
handling character sequences
* Signature for entity_manager
* Examples
* Pull parser DONE
* Review Pullparser + Entry_expr
* Namespaces
TODO: test
* Pxp_ev_parser: stream parser
(In Kommentar erlutert) DONE
* Pxp_ev_parser: Filter, der ignorable whitespace lscht
DONE
* Filter, der char data normalisiert
DONE
* CHECK: Attributwerte
* Pxp_document: erzeugen aus event stream; abbilden in event stream
* Wie bricht man einen stream parser vorzeitig ab? Dateien schlieen!
* Namespaces und DTDs: Eine pxp:dtd processing instruction, um den
Default-Namespace fr Element-Deklarationen in DTDs zu setzen.
<?pxp:dtd xmlns="..."?>
- Follow-Ups:
* Clean-up of lexer definitions
???
* Clean-Up of pxp_yacc.m2y: separate tree_parser and event_parser.
They have a common superclass where event methods are virtual.
Pxp_grammar: Contains grammar and state classes
Pxp_parse_tree: Only entry points for tree parser
Pxp_parse_events: Only entry points for event-based parser
Pxp_yacc: compatibility interface
DONE
* extend_dtd: export? DONE
* standalone DONE
* Clean-Up of Pxp_entity. At least define class type entity (in .ml).
* Pxp_light: XML-Baum als rekursiver Typ
Pxp_light_trans: Light-Darstellung von/nach Heavy-Darstellung konvertieren
Pxp_light_docemu: Light-Darstellung als Document-kompatible Klasse
NICHT IN PXP 1.2
* Undo pxp_lexing.mlp DONE
- Improvements:
* Clone nodes and change DTD
* parse_wfdocument_entity: argument ~share_dtd
* pxp_reader uses netchannels instead of channels
DONE
- pxpvalidate braucht hook um Baum teilweise zu lschen.
- Packen:
* pxp.files aktualisieren
* pxp_wlex_utf8_01.ml vorgenerieren
------------------------------
- Klasse wfdocument???
Problemlage:
- Bei Wf-dokumenten keine Deklarationen ausgeben (ausser entities)
==> Knnten auch write-Optionen leisten
- keine allow_arbitrary-PI ausgeben
- berprfung des root-Elements separieren
------------------------------
- Pxp_lexing: fast_from_function programmieren, das direkt den lexbuf
benutzt.
- Pxp_dtd.Entity: get_resolver
- Pxp_entity: method copy (relocate)
- Pxp_marshal.relocate_document: copy the entities, too
- Resolvers: get_base_uri
NICHT NOTWENDIG, active_id des parent-resolvers tut es.
------------------------------
- Separate well-formed documents from validated documents
+ Generalize DTDs so that schemas can be implemented
- PXP 1.2: Adapter to Nethtml: Parses HTML and converts it to a PXP object
tree.
==> module Pxp_html
- PXP 1.2: embedded XML (see below)
- PXP 1.2: XPATH
==> module Pxp_xpath definiert XPATH-Kernfunktionen
- PXP 1.2: Adapter to Netclient
Problems with Pxp_reader: there should be some notion of "relative URI"
vs. "absolute URI". Currently, processing of relative URIs works only
if the active resolver always accepts relative URIs. I.e. it works but
is error-prone.
Idea: open_in has new argument ~scheme:
- Some "http": The URI is absolute
- Some "": The URI is empty, or Private, or Anonymous
- None: The URI is relative
'combine' would interpret the rejection of a relative URI as an error.
Pxp_reader: Perhaps a Redirection exception could be useful.
See netclient.
Pxp_document: The representation of the children list needs to be
improved. Perhaps a balanced tree would work well that allows accesses
by index.
----------------------------------------------------------------------
- E-XML:
<dtd< dtd material >>
<element< xml material >> --> transformiert in eine FUNKTION, die mit
create_xxx den Term zusammenbaut. Mittels $-Notation lt sich angeben,
welche (benannten) Argumente die Funktion hat.
<data< text material >>
spec, dtd: aus dem Environment
${name:string}: Ein String wird in das Attribut/Textknoten eingefgt
{string <ocaml-name>}
${name:att_value}: Das Attribut wird auf den att_value gesetzt.
NUR so: attribut="${name:att_value}"
{att_value <ocaml-name>}
${name:node}: Ein einzelner Knoten
{node <ocaml-name>}
${name:nodelist}: Eine liste von Knoten
{nodes <ocaml-name>}
Beispiel:
let m = <element< <a href="abc">The hyperlink to ${dest:string}</a> >>
let m = <element< <a href="abc">The hyperlink to {string dest}</a> >>
Ergibt: m : string -> 'ext node
m : dest:string -> 'ext node
Die Leerzeichen vor <a> und nach </a> werden ignoriert
spec, dtd: feste ocaml-Bezeichner
<xml< <element>...</element> >>
<xml< <?pi ...?> >>
<xml< <!-- ... --> >>
<xml< data >> (Leerzeichen am Anfang und Ende ignoriert)
Der XML-Ausdruck wird im well-formed-Modus gelesen. Daher wird kein
ignorable whitespace erkannt.
<declaredtd< DTD >> ??? (later)
- Entity-Definitionen benutzen
- Validierung des Ausdrucks ??? Geht evtl. nicht
- Ignorable whitespace
Namespaces?
The functor should get a set of nodes as argument, so one can experiment
with various set implementations.
......@@ -95,13 +95,13 @@ odoc: html/pic/done
rm -rf html/ref
mkdir -p html/ref
cp style.css html/ref
ocamldoc -g ../../tools/src/odoc/chtml.cmo \
ocamldoc -v -g ../../tools/src/odoc/chtml.cmo \
-t "PXP Reference" \
-I ../../src/pxp-engine \
-load ../../src/pxp-engine/pxp_engine.dump \
-d html/ref \
-colorize-code \
-css-style style.css
-css-style style.css -intro index.txt
......
{1 The [readme] processor}
{fixpxpcoretypes true}
The task of the [readme] processor is to convert a document conforming
to the XML DTD "readme.dtd" into an HTML document or a text document.
This example especially demonstrates how to use node extensions to add
......@@ -483,7 +485,7 @@ value is determined by invoking [self # node # attribute "title"] (see
{!Pxp_document.node.attribute}). As this attribute has been declared
as CDATA and as being required, the value has always the form [Value
s] where [s] is the string value of the attribute. Attribute values
have type {!Pxp_types.att_value}.
have type {!Pxp_core_types.S.att_value}.
You can also see how entity contents can be accessed. A parameter
entity object can be looked up by [self # node # dtd # par_entity
......@@ -842,3 +844,5 @@ let main() =
let () =
main()
]}
{fixpxpcoretypes false}
......@@ -117,23 +117,19 @@ The parser emits events for
Note that the short form of empty elements, [<tag/>] are emitted as
a start tag followed by an end tag.
}
{- [E_pinstr(name,value,entid)] and
[E_pinstr_member(name,value,entid)]: Processing instructions
{- [E_pinstr(name,value,entid)]: Processing instructions
(PI's) - In tree mode, PI's can be represented in two ways: Either by
attaching them to the surrounding elements, or by including them
into the tree exactly where they occurred in the text. For symmetry,
the same two ways of handling PI's are also present in the event
stream representation (event streams and trees should be convertible
into each other without data loss). This means there are two events,
one ([E_pinstr_member]) indicating to attach the PI to the surrounding
element, and one ([E_pinstr])
indicating to include the PI at its position. The two events carry
the same information: the [name] of the PI, the [value], and a
reference [entid] to the entity it occurs in. Usually, user code processing
event streams can handle both event types in exactly the same
way. As in tree mode, there is the config option (see {!Pxp_types.config})
[enable_pinstr_nodes] controlling which type of event is emitted.
If [true], the parser emits [E_pinstr], otherwise [E_pinstr_member].
into each other without data loss). Although there is only one
event ([E_pinstr]), it depends on the config option
[enable_pinstr_nodes] where this event is placed into the event
stream. If the option is enabled, [E_pinstr] is always emitted where
the PI occurs in the XML text. If it is disabled, the emission of
[E_pinstr] may be delayed, but it is still guaranteed that this
happens in the same context (surrounding element).
It is not possible to turn the emission of PI events completely
off. (See {!Intro_events.filters} for an example how to filter out
PI events in a postprocessing step.)
......@@ -291,8 +287,7 @@ the parser driver.
{[
let config = Pxp_types.default_config
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let entmng = Pxp_ev_parser.create_entity_manager config source
]}
......@@ -648,8 +643,7 @@ e.g. adding filters, to see the effect.
{[
let config = Pxp_types.default_config
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let entmng = Pxp_ev_parser.create_entity_manager config source
let pull = create_pull_parser config entry entmng
let () = Pxp_event.iter
......
This text explains the custom node extensions that can be attached
to XML trees. This feature can be ignored by users that do not need
it. We effectively comment the class type {!Pxp_document.extension}
it. We effectively comment the class type {!classtype:Pxp_document.extension}
here.
{1 Node extensions}
......@@ -10,7 +10,7 @@ extension is practically empty and only present for formal uniformity.
However, one can also define custom extension classes, and effectively
make new methods available to nodes.
The type {!Pxp_document.extension} is:
The type {!classtype:Pxp_document.extension} is:
{[
class type [ 'node ] extension =
......@@ -65,7 +65,7 @@ data nodes.
At minimum, you must define the methods [clone], [node], and
[set_node] such that your class is compatible with the type
{!Pxp_document.extension}. The method [set_node] is called during the
{!classtype:Pxp_document.extension}. The method [set_node] is called during the
initialization of the node, or after a node has been cloned; the node
object invokes [set_node] on the extension object to tell it that this
node is now the object the extension is linked to. The extension must
......@@ -101,7 +101,7 @@ class custom_extension =
end
]}
This class is compatible with {!Pxp_document.extension}. The purpose
This class is compatible with {!classtype:Pxp_document.extension}. The purpose
of defining such a class is, of course, adding further methods; and
you can do it without restriction.
......
......@@ -10,8 +10,7 @@ The basic piece of code to parse "filename.xml" is:
{[
let config = Pxp_types.default_config
let spec = Pxp_tree_parser.default_spec
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let doc = Pxp_tree_parser.parse_document_entity config source spec
]}
......@@ -28,17 +27,18 @@ and {!Pxp_tree_parser.default_spec}). These defaults have these effects
- No namespace processing is performed.
XML does not know the concept of file names. All files (or other
resources) are named by so-called ID's. Here we choose to convert
the file name into a [SYSTEM] ID which is essentially a URL of the
form [file:///dir1/.../dirN/filename.xml]. This ID can be processed -
resources) are named by so-called ID's. Although we can pass here a
file name to [from_file], it is immediately converted into a [SYSTEM]
ID which is essentially a URL of the form
[file:///dir1/.../dirN/filename.xml]. This ID can be processed -
especially it is now clear how to treat releative [SYSTEM] ID's that
occur in the parsed document. For instance, if another file is included
by "filename.xml", and the [SYSTEM] ID is "parts/part1.xml", the usual
rules for resolving relative URL's say that the effective file to read
is [file:///dir1/.../dirN/parts/part1.xml]. Relative [SYSTEM] ID's are
resolved relative to the URL of the file where the entity reference
occurs that leads to the inclusion of the other file (this is comparable
to how hyperlinks in HTML are treated).
occur in the parsed document. For instance, if another file is
included by "filename.xml", and the [SYSTEM] ID is "parts/part1.xml",
the usual rules for resolving relative URL's say that the effective
file to read is [file:///dir1/.../dirN/parts/part1.xml]. Relative
[SYSTEM] ID's are resolved relative to the URL of the file where the
entity reference occurs that leads to the inclusion of the other file
(this is comparable to how hyperlinks in HTML are treated).
Note that we make here some assumptions about the file system of the
computer. {!Pxp_reader.make_file_url} has to deal with character
......@@ -214,16 +214,14 @@ Also [doc] is the parsed "filename.xml" file as retrieved by
{[
let config = Pxp_types.default_config
let spec = Pxp_tree_parser.default_spec
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let doc = Pxp_tree_parser.parse_wfdocument_entity config source spec
]}
Now the validation against a different DTD is done by:
{[
let rdtd_url = Pxp_reader.make_file_url "file.dtd"
let rdtd_source = Pxp_types.from_file (Neturl.string_of_url rdtd_url)
let rdtd_source = Pxp_types.from_file "file.dtd"
let rdtd = Pxp_dtd_parser.parse_dtd_entity config rdtd_source
let () = rdtd # set_root "start"
let vroot = Pxp_marshal.relocate_document doc#root rdtd spec
......@@ -327,8 +325,7 @@ Here we show how to parse "filename.xml" with a pull parser:
{[
let config = Pxp_types.default_config
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let entmng = Pxp_ev_parser.create_entity_manager config source
let entry = `Entry_document []
let next = Pxp_ev_parser.create_pull_parser config entry entmng
......@@ -357,8 +354,7 @@ A tree node is either an [Element(name,atts,children)] or a
{[
let config = Pxp_types.default_config
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let entmng = Pxp_ev_parser.create_entity_manager config source
let entry = `Entry_document []
let next = Pxp_ev_parser.create_pull_parser config entry entmng
......@@ -571,8 +567,7 @@ whether [IDREF] attributes only point to existing nodes. The code:
{[
let config = { Pxp_types.default_config with idref_pass = true }
let spec = Pxp_tree_parser.default_spec
let file_url = Pxp_reader.make_file_url "filename.xml"
let source = Pxp_types.from_file (Neturl.string_of_url file_url)
let source = Pxp_types.from_file "filename.xml"
let hash_index = new Pxp_tree_parser.hash_index
let id_index = (hash_index :> _ Pxp_tree_parser.hash_index)
let doc = Pxp_tree_parser.parse_document_entity ~id_index config source spec
......
......@@ -41,15 +41,22 @@ chapter of the PXP manual explains how to do this.
{2 Various types that are involved}
The simple form of an (external) entity ID is {!type:Pxp_types.ext_id}: It
The simple form of an (external) entity ID is {!Pxp_core_types.S.ext_id}: It
enumerates the four cases:
- [System url]
- [Public(public_name, system_url)]
- [Private p]
- [Anonymous]
Tip: To create an URL from a filename, use
{[
let file_url = Pxp_reader.make_file_url filename
let file_url_string = Neturl.string_of_url file_url
]}
During resolution, a different representation of the ID is preferred -
{!Pxp_types.resolver_id}:
{!Pxp_core_types.S.resolver_id}:
{[
type resolver_id =
......
......@@ -7,14 +7,16 @@ Also note that there is also a stream representation of XML. See
{1 The structure of document trees}
In a document parsed with the default parser settings every node represents
either an element or a character data section. There are two classes
implementing the two aspects of nodes: {!Pxp_document.element_impl},
and {!Pxp_document.data_impl}. There are configurations which allow more
node types to be created, in particular processing instruction nodes,
comment nodes, and super root nodes, but these are discussed later.
Note that you can always add these extra node types yourself to the node tree
no matter what the parser configuration specifies.
In a document parsed with the default parser settings every node
represents either an element or a character data section. There are
two classes implementing the two aspects of nodes:
{!classtype:Pxp_document.element_impl}, and
{!classtype:Pxp_document.data_impl}. There are configurations which
allow more node types to be created, in particular processing
instruction nodes, comment nodes, and super root nodes, but these are
discussed later. Note that you can always add these extra node types
yourself to the node tree no matter what the parser configuration
specifies.
The following figure
shows an example how
......@@ -31,6 +33,7 @@ Attributes (the clouds in the picture) do not appear as nodes of the
tree, and one must use special access methods to get them.
You would get such a tree by parsing with
{[
let config = Pxp_types.default_config
let source = Pxp_types.from_string
......@@ -44,7 +47,7 @@ The [config] record sets a lot of parsing options. A number of these
options are explained below. The [source] argument says from where
the parsed text comes. For the mysterious [spec] parameter see below.
The parser returns [doc], which is a {!Pxp_document.document}. You
The parser returns [doc], which is a {!classtype:Pxp_document.document}. You
have to call its [root] method to get the root of the tree. Note that
there are other parsing functions that return directly nodes; these
are intended for parsing XML fragments, however. For the usual closed
......@@ -114,13 +117,13 @@ data nodes by calling the {!Pxp_document.node.attributes} method,
although this does not
make sense. This problem is resolved on a case-by-case basis by
either returning an "empty value" or by raising appropriate
exceptions (e.g. {!Pxp_types.Method_not_applicable}).
exceptions (e.g. {!Pxp_core_types.S.Method_not_applicable}).
For the chosen typing it is not possible to define slimmer class types
that better fit the various node types.
Attributes are usually represented as pairs
[string * att_value] of names and values. Here,
[att_value] is a conventional variant type. There are lots of
{!Pxp_core_types.S.att_value} is a conventional variant type. There are lots of
access methods for attributes, see below. It is optionally possible
to wrap the attributes as nodes (method
{!Pxp_document.node.attributes_as_nodes}), but even in this case the attributes
......@@ -422,9 +425,10 @@ that do not impose restrictions on the document:
Even such a DTD object can contain entity definitions, and can demand
a certain way of dealing with namespaces. Also, the character encoding
of the nodes is taken from the DTD. See {!Pxp_dtd.dtd} for DTD methods,
and {!Pxp_dtd_parser} for convenient ways to create DTD objects. Note
that all nodes of a tree must be connected to the same DTD object.
of the nodes is taken from the DTD. See {!classtype:Pxp_dtd.dtd} for
DTD methods, and {!Pxp_dtd_parser} for convenient ways to create DTD
objects. Note that all nodes of a tree must be connected to the same
DTD object.
PXP is not restricted to using built-in classes for nodes. When the
parser is invoked and a tree is built, it is looked up in a so-called
......@@ -515,7 +519,7 @@ The XML specification allows all Unicode characters in XML
texts. This parser can be configured such that UTF-8 is used to represent the
characters internally; however, the default character encoding is
ISO-8859-1. (Currently, no other encodings are possible for the internal string
representation; the type {!Pxp_types.rep_encoding} enumerates
representation; the type {!Pxp_core_types.S.rep_encoding} enumerates
the possible encodings. Principally, the parser could use any encoding that is
ASCII-compatible, but there are currently only lexical analyzers for UTF-8 and
ISO-8859-1. It is currently impossible to use UTF-16 or UCS-4 as internal
......
......@@ -18,6 +18,7 @@
open Pxp_types
open Pxp_dtd
(** {fixpxpcoretypes true} *)
(** {2 The node type} *)
......@@ -101,6 +102,7 @@ class type [ 'node ] extension =
;;
(** The class type [node] defines the interface of the nodes that are part
of XML document trees. For an introduction into trees, see
{!Intro_trees}.
......@@ -119,6 +121,7 @@ class type [ 'node ] extension =
class type [ 'ext ] node =
object ('self)
constraint 'ext = 'ext node #extension
(** {fixpxpcoretypes true} *)
(** Domain
......@@ -128,8 +131,8 @@ class type [ 'ext ] node =
is documented below, and also any unusual reaction when the
methods are called nevertheless. The standard rection is to raise
either the exception
{!Pxp_types.Method_not_applicable} or
{!Pxp_types.Namespace_method_not_applicable} for namespace-specific
{!exception:Pxp_core_types.S.Method_not_applicable} or
{!exception:Pxp_core_types.S.Namespace_method_not_applicable} for namespace-specific
methods.
*)
......@@ -549,6 +552,8 @@ class type [ 'ext ] node =
* modification of the attribute list, and it will return the same list
* again in subsequent invocations.
*
* See also {!Intro_advanced.irrnodes}.
*
* {b Domain.} This method is only applicable to elements.
*)
......@@ -1100,7 +1105,7 @@ class type [ 'ext ] node =
Namespace methods are only available in namespace-aware implementations
of [node]. For other implementations, the exception
{!Pxp_types.Namespace_method_not_supported} is raised.
{!Pxp_core_types.S.Namespace_method_not_applicable} is raised.
Keep in mind that PXP applies prefix normalization. For an
introduction see {!Intro_namespaces}.
......@@ -1224,6 +1229,8 @@ class type [ 'ext ] node =
* nodes when it is first invoked, and it will return the same list
* again in subsequent invocations.
*
* See also {!Intro_advanced.irrnodes}.
*
* {b Domain.} This method is only applicable to elements that
* support namespaces.
*)
......@@ -1709,7 +1716,7 @@ val create_no_node :
(** {2 Document order} *)
(** {2:docorder Document order} *)
(** The functions [compare] and [ord_compare] implement the so-called
......@@ -2295,3 +2302,5 @@ val liquefy :
* - [omit_positions]: If true, no [E_position] events are generated.
* Default:false.
*)
(** {fixpxpcoretypes false} *)
......@@ -85,7 +85,7 @@ val process_entity :
* Currently not supported. (But see {!Pxp_dtd_parser} for functions
* parsing DTDs.)
* - [`Entry_expr]: Do not pass this entry point! There is the specially
* crafted function {!Pxp_ev_parser.parse_expr} for it.
* crafted function {!Pxp_ev_parser.process_expr} for it.
*
* The entry points have options, see {!Pxp_types.entry} for explanations.
*
......
......@@ -7,7 +7,7 @@
(** Calling the parser in tree mode *)
(** The following functions return the parsed XML text as tree, i.e.
as {!Pxp_document.node} or {!Pxp_document.document}.
as {!Pxp_document.node} or {!classtype:Pxp_document.document}.
*)
open Pxp_dtd
......
......@@ -37,6 +37,8 @@ include Pxp_core_types.S
{knowntype Pxp_types.output_stream}
{knowntype Pxp_types.pool}
{knowntype Pxp_types.Method_not_applicable}
{knownclass Pxp_types.drop_warnings}
*)
......@@ -110,7 +112,7 @@ type config =
* Note that processing instructions in the DTD part of the XML
* text are not meant here (i.e. instructions between the square
* brackets, or in an external DTD). These instructions are always
* attached to the DTD object (see {!Pxp_dtd.dtd}).
* attached to the DTD object (see {!classtype:Pxp_dtd.dtd}).
* - If [enable_comment_nodes] is also true, comment nodes can
* occur as children of the super root node when comments
* occur before or after the root element. If [enable_comment_nodes]
......
......@@ -115,7 +115,7 @@ class type [ 'ext ] index = [ 'ext ] Pxp_tree_parser.index
(** Same as {!Pxp_tree_parser.index} *)
class [ 'ext ] hash_index : [ 'ext ] Pxp_tree_parser.hash_index
(** Same as {!Pxp_tree_parser.hash_index} *)
(** Same as {!classtype:Pxp_tree_parser.hash_index} *)
val default_extension : ('a node extension) as 'a
(** Same as {!Pxp_tree_parser.default_extension} *)
......
......@@ -128,6 +128,16 @@ prerr_endline "picture found";
s in
super # create_fully_qualified_idents_links m_name s'
method html_of_Ref b name ref_opt =
let name' =
if enable_fix_pxp_core_types then (
(* prerr_endline ("Ref: " ^ name); *)
Str.global_replace pxp_core_types_re "Pxp_types." name
)
else
name in
super # html_of_Ref b name' ref_opt
method add_known_type t =
List.iter
(fun s ->
......@@ -142,7 +152,6 @@ prerr_endline "picture found";
)
(split_args t)
method html_of_custom_text b s t =
match s with
| "{picture" -> self#html_of_picture b t
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment