Commit aa9055f7 authored by gerd's avatar gerd

continued


git-svn-id: https://godirepo.camlcity.org/svn/lib-pxp/trunk@736 dbe99aee-44db-0310-b2b3-d33182c8eb97
parent 58b16ec0
......@@ -5,7 +5,7 @@
open Pxp_types
open Pxp_document
open Pxp_yacc
open Pxp_tree_parser
let rec print_error e =
......
......@@ -20,7 +20,9 @@ DOC = pxp_types.mli pxp_document.mli pxp_dtd.mli pxp_tree_parser.mli \
pxp_event.mli pxp_dtd_parser.mli pxp_codewriter.mli \
pxp_marshal.mli pxp_yacc.mli pxp_reader.mli \
intro_trees.txt intro_extensions.txt intro_namespaces.txt \
intro_events.txt intro_resolution.txt intro_getting_started.txt
intro_events.txt intro_resolution.txt intro_getting_started.txt \
intro_advanced.txt \
example_readme.txt
XOBJ = $(OBJ:.cmo=.cmx)
......
This diff is collapsed.
......@@ -8,7 +8,7 @@ here.
Every node in a tree has a so-called extension. By default, the
extension is practically empty and only present for formal uniformity.
However, one can also define custom extension classes, and effectively
add new methods to the node classes.
make new methods available to nodes.
The type {!Pxp_document.extension} is:
......@@ -201,3 +201,10 @@ let spec =
The extension object [c] is still used for all data nodes and
for all other element types.
{2 An example}
A complete example using extension objects is the [readme]
processor. The full source code is included in the PXP source tarball.
A commented version is available here: {!Example_readme}.
This diff is collapsed.
......@@ -48,18 +48,18 @@ to enable all that:
let root = doc#root
]}
The namespace-aware implementations of the [node]
class type define additional namespace methods like
[namespace_uri]. (Although you also could direct the parser to create
non-namespace-aware nodes,
this does not make much sense, as you do not get these special access
methods then.)
The method [namespace_scope] allows one to get more information what
happened during prefix normalization. In particular, it is possible to
find out the original prefix in the XML text (which is also called
{b display prefix}), before it was mapped to the normalized prefix.
The [namespace_scope] method returns a
The namespace-aware implementations of the [node] class type define
additional namespace methods like [namespace_uri] (see
{!Pxp_document.node.namespace_uri}). (Although you also could direct
the parser to create non-namespace-aware nodes, this does not make
much sense, as you do not get these special access methods then.)
The method [namespace_scope] (see
{!Pxp_document.node.namespace_scope}) allows one to get more
information what happened during prefix normalization. In particular,
it is possible to find out the original prefix in the XML text (which
is also called {b display prefix}), before it was mapped to the
normalized prefix. The [namespace_scope] method returns a
{!Pxp_dtd.namespace_scope} object with additional lookup methods.
......@@ -80,11 +80,13 @@ for the XHTML namespace:
]}
In this example, normalization changes nothing, because the prefix
"h" has the same meaning thoughout the whole document.
"h" has the same meaning thoughout the whole document. However, keep
in mind that every author of XHTML documents can freely choose the
prefix to use.
The XML standard, however, gives the author of the document the
freedom to change the meaning of the prefix at any time. For example,
here the prefix "x" is changed in the inner node:
The XML standard gives the author of the document even the freedom to
change the meaning of a prefix at any time. For example, here the
prefix "x" is changed in the inner node:
{[
<x:address xmlns:x="http://addresses.org">
......@@ -94,6 +96,10 @@ here the prefix "x" is changed in the inner node:
</x:address>
]}
In the outer node the prefix "x" is connected with the
"http://addresses.org" namespace, but in the inner node it is
connected with "http://names.org".
After normalization, the prefixes would look as follows:
{[
......@@ -105,7 +111,7 @@ After normalization, the prefixes would look as follows:
]}
In order to avoid overridden prefixes, the prefix in the inner node
was changed to "x1".
was changed to "x1" (for type theorists: think of alpha conversion).
The idea of prefix normalization is to simplify how programs can match
against element and attribute names. It is possible to configure the
......@@ -155,12 +161,12 @@ use them directly in programs, e.g. for matching:
]}
{2 Finding out more about namespaces}
{2 Getting more details of namespaces}
There are two additional objects that are relevant. First, there is a
namespace manager for the whole tree. This object gathers all namespace
URI's up that occur in the XML text, and decides which normprefixes
are associated with them: {!Pxp_dtd.namespace_manager}.
are associated with them: {!classtype:Pxp_dtd.namespace_manager}.
Second, there is the namespace scope. An XML tree may have a lot of such
objects. A new scope object is created whenever new namespaces are
......
......@@ -1024,6 +1024,11 @@ class type [ 'ext ] node =
* added, if possible. If [valcheck=false], any element type
* and any attributes are accepted.
*
* Even in well-formedness mode, it is ok to pass [valcheck=true]
* as this mode is implemented by weakening the validation
* constraints in the DTD object. See
* {!Intro_getting_started.wfmode} for explanations.
*
* If a [name_pool_for_attribute_values] is passed, the attribute
* values in [att_list] are put into this pool.
*
......@@ -1076,6 +1081,9 @@ 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.
Keep in mind that PXP applies prefix normalization. For an
introduction see {!Intro_namespaces}.
*)
method normprefix : string
......@@ -1094,8 +1102,8 @@ class type [ 'ext ] node =
* method returns the display prefix of the element or attribute.
* If the object does not have a prefix, "" will be passed back.
*
* The display prefix is the prefix as it occurs literally in the XML
* text.
* The display prefix is supposed to be the prefix as it occurs
* literally in the XML text.
*
* Actually, this method does not return the real display prefix
* that was found in the XML text but the most recently declared
......@@ -1620,6 +1628,12 @@ val create_element_node :
* is left out; in this case you can pass any element type and
* and any attributes, and it does not matter whether and how
* they are declared.
*
* Even in well-formedness mode, it is ok to pass [valcheck=true]
* as this mode is implemented by weakening the validation
* constraints in the DTD object. See
* {!Intro_getting_started.wfmode} for explanations.
*
*)
val create_super_root_node :
......
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