#d2d 2.0 text using mtdocpage : webpage #title Collected White Papers on Technical Details #htmlTitle bandm metatools: Collected White Papers on Technical Details #lang en #tableOfContents #commentchar \ \\ ========================================================================= #h1 #title Intentions \\ ========================================================================= #p In #mt, most areas of processing are neatly separated and cleanly implemented. But there are some processes and data-flows the details of which are not only rather complicated, but also distributed over different modules and layers of the architecture. #p (In most cases, this is due to #emph!external! standards and tools we have to interface !-) #p For these topics, a central "White Paper" is desirable which describes at one central place the coding principles (the basic design decisions as well as the details) and sketches the co-operation of the modules involved. #p Some of these "little white papers" will be collected here. The collection itself is rather #ital!ad hoc!, ie. not carefully structured or aiming at completeness. It will grow as soon as new topics are identified as useful and desired. \\ ========================================================================= #h1 #title Identifying, Searching and Finding of Resources \\ ========================================================================= \\ ========================================================================= #h2 #title XML Document Identifier \\ ========================================================================= #p The XML Document Identifier (=XML-DI in this text) is implicitly defined in #link 0/www.w3.org/TR/xml11/ #loc NT-ExternalID #top #/link [=XML] #nl It is implemented in #mt in #link 4/message/XMLDocumentIdentifier.html#text message.XMLDocumentIdentifier#/link #nl The "SYSTEM" part must be a URL. #nl #link 0/webdesign.about.com/od/dtds/qt/tipdoctype.htm #top #/link says that in case of a PUBLIC id present "The rest of the DOCTYPE identifier is optional..", but the syntax graph in [XML] says different! #p The "PUBLIC" part is not defined in the XML standard. #emph!Only traditionally! it is a "Formal Public Identifier" = "FPI" as defined in SGML (= ISO 8879:1986) / (ISO 9070:1991) #p See #link 0/en.wikipedia.org/wiki/Formal_Public_Identifier #top #/link[=WIKIFPI] #p #link 0/www.ietf.org/rfc/rfc3151.txt #top #/link contains a proposal for mapping FPIs into an URN namespace #p Following [WIKIFPI], WE as a domain owner have a registered (!!) FPI, namely #nl #src! +//IDN eu.bandm//...! This is supported in some methods in #link 4/dtd/Utilities.html#/link \\ ========================================================================= #h2 #title XML-DIs in Documents \\ ========================================================================= #p A doctype declaration of an XML encoded text consists of a TAG, namely the tag of the root element, and a DTD reference. This is in form of an XML-DI. #nl Our implementation of DTD includes a field for this XML-DI. #nl This is conceptually NOT CLEAN, because the "system" part of "the same" DTD may differ between computer systems or even applications or even runs, while the "public" part must be identical. #nl Nevertheless, XML requries the system part to be always present, and to treat both parts as a unit. #p The XML-DI of a DTD can be encoded into a PI for tdom, so that TDOM gets to know it. This is done in the WRAPPER DTD, in case a third-party DTD shall be processed by tdom. The #link 4/tdom/TypedDOMGenerator.html#text TypedDOMGenerator#/link compiles this id into a static final field in the generated sub-class of #link 4/tdom/runtime/TypedDTD.html#text TypedDTD#/link. It can be retrieved by calling #link 4/tdom/runtime/TypedDTD.html#loc getDocumentId()#/link #p The method #link 4/dtd/Utilities.html #loc addTdomPI_documentId(eu.bandm.tools.dtd.DTD.Dtd) #text dtd.Utilities.addTdomPI_documentId(Dtd) #/link generates such a PI for a dtd as an internal model. #p Whenever a #link 4/util2/ContentPrinter.html#text ContentPrinter#/link gets the first "startElement" SAX call, it prints XML version and encoding, followed by a synthesized "DOCTYPE" declaration. For this, the "document locator" must be have been set in advance by a call to the method #link 4/util2/ContentPrinter.html #loc setDocumentLocator(org.xml.sax.Locator)#/link #nl This is a standard function from #link 0/java.sun.com/j2se/1.5.0/docs/api/org/xml/sax/ContentHandler.html #text org.xml.sax.ContentHandler #top #/link [=SAX-ContenHandler] #p In our context, this method is called e.g. by DUMPER CODE GENERATED by tdom. See eg. #link 3/eu/bandm/tools/doctypes/xhtml/Dumper.java#/link, method "#src!match (Document_html)!" #p BUT THIS SEEMS AN ABUSE, because [SAX-ContenHandler] says this location is the ORIGIN of the sax events, i.e. the document itself, not the origin of its type definition !?!?!? \\ ========================================================================= #h2 #title Locating Documents by URL/URI/URN \\ ========================================================================= #p The class #link 4/doctypes/DocTypes.html #/link implements a "URI Resolver" interface. The procedure defintions in "calltools.mk" named "xml2text", "xml2html", "xml2xml" (more may come!) all call "xalan". They attribute the call to the #bold Xalan command line#/ by "#src!-URIRESOLVER eu.bandm.tools.doctypes.DocTypes!". #p The code of #link 4/doctypes/DocTypes.html #loc resolve(java.lang.String, java.lang.String) #text resolve(uri,base)#/link delivers for requests for URIs like #src!bandm.eu/doctypes//! and #nl #src!http://bandm.eu/doctypes//!#nl a "javax.xml.transform.Source" instance object which points to a "getResouceAsStream()"-resource named #src!/!, -- relative to the class file of DocTypes. #p This is employed e.g. to find some files with xslt-procedures which are included in the main transformation file. #p remark 1) #nl #bold The "PUBLIC ID" (which does belong to us !-) is currently NOT DECODED.#/bold #p remark 2) #nl The currently used "CMDLINE-WRAPPER" for xantlr #bold does NOT use the uri decoder for the top-level (=commandline argument) files! #/bold But it should be eliminated anyhow by a wrapper around the JAXP/TRAX interface. \\ ========================================================================= #h1 #title Locations and Locators, i.e. position IN a particular document \\ ========================================================================= #p \\ ========================================================================= #h2 #title Locators in SAX \\ ========================================================================= #p There is an interface definition #link 0/www.saxproject.org/apidoc/org/xml/sax/Locator.html #text org.xml.sax.Locator#/link. which offers different methods for #emph!inquiring! the different coordinates of the current input position (e.g. #src!getColumnNumber()!, #src!getSystemId()!). #p The function #link http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html #loc setDocumentLocator(org.xml.sax.Locator) #text ContentHandler.setDocumentLocator(org.xml.sax.Locator locator) #/link should be called "under the hood" by an XML "stream" parser to set the implementing object. It is NOT guaranteed that every XML parser does so. #p#kind missing MORE TO COME \\ ========================================================================= #h2 #title Locations in the d2d/xml/xslt pipelines \\ ========================================================================= #p (This is a more internal topic, but we need a kind of memo, so we put it here!-) #p #list #i #link 4/d2d2/base/ModuleRegistry.html #loc loadXslt(eu.bandm.tools.d2d2.model.Module, java.lang.String, java.lang.String) #text Moduleregistry.loadXslt()#/link loads the ddf module as usual. All trees in the AST-TDom get their normal XML location information. #i ADDITIONALLY the documentation texts #nl (resulting from inputs like "#src!docu to_filelist article!" or "#src!docu user_en article!") #nl are wrapped into a #link 4/d2d2/model/LocString.html #text a special "LocString" object #/link (read: located String), because LINE BREAKS in continguous char data must be respected for the location map. #i #label iMAP Then the #link 4/d2d2/base/Def2Xslt.html #text Def2Xslt processor#/link extracts the source text of the xslt rules into #emph!one large string! and fills the map "stringpos2filepos" accordingly #i The #link 4/d2d2/base/Text2Udom.html #text Text2Udom parser#/link constructs XMLDocumentIdentifier from the text input, may it be file or string, and stores them in the ResultingStructures. Since a #link 4/d2d2/infra/MemString.html #text MemString#/link is used, line numbering #emph!starts with zero!! #i Interleaved, the MemString data is integrated without changes into the output and comes with the original location information. #i The Udom2Sax generates Sax Events and implements the Sax Locator callback interface, which translates (via a cache!) these infos. #i In case that the Sax events are fed into an XSLT compiler (like XALAN), and this finds an error, we expert this to call that call-back method. #i Most errors are reported by thrown exceptions. This is very annoying. The exceptions must be UN-WRAPPED to find the locator information. In most cases a #link 5/javax/xml/transform/TransformerException.html #text javax.xml.transform.TransformerException #/link can be found wrapped inside, and this carries the location information. #nl This can e.g. be wrapped into a #link http://xml.apache.org/xalan-j/apidocs/org/apache/xml/utils/WrappedRuntimeException.html #text org.apache.xml.utils.WrappedRuntimeException #/link. #nl Or into a TransformerException or into a SAXException or into #ldots #nl CAVEAT ONE: The very first variant can only be compiled when an appropriate "Xalan-mixture" is in the classpath of the COMPILATION STEP! #nl CAVEAT TWO: It is UNSPECIFIED which exceptions can be thrown, and what they contain. We try to decode as much as possible to generate sensible error messages, but this is not guaranteed, and catch the upper limit (Exception) to generate an "error not understood error"-message #nl Both points are VERY ANNOYING! #i Once found, the location information is easily re-transposed for the user with the map from #ref iMAP ! #/list \\ ========================================================================= #h1 #title XML Namespaces \\ ========================================================================= #h2 #title Namespace Definition, Encoding in Documents #p XML "Namespaces" and "Namespace Names" are complicated because they reflect a complex history of parallel/sequential, competing/co-operative, clean/hacking developments. Different interfaces and third-party-modules (eg SAX, Xalan) impose different constraints on their input wrt. name spaces, and these are not always fully and exactly specified! #p Basically, some tools and sub-specifications of the XML family do not consider namespaces at all (e.g. the XML base specification, the DTD mechanism, #cite xml). Others can work in two different modes, either namespace aware or not. A third group does always consider name spaces (XPath, XSL-T). #p Whenever name spaces are considered, this applies to all kinds of #emph!identifiers!, namely element tags, attribute names, and (eg. in XPath and XSLT) names of variables, functions, templates, modes, etc. #p Our class #link 4/util/NamespaceName.html#text NamespaceName#/link in a first step seems to make things even more complicated, to make them more easy, namely interoperable, in a second step! The basic philosophy of this class it trying to combine requirements from different sources: #p In XML in general #cite xml , in non-namespace mode the colon ":" is a normal character which may occur arbitrarily often in any identifier (tag or attribute name, etc.) #p But in namespace mode there may be maximally ONE(1) colon ":", separating a non-empty prefix and a non-empty local name, see #cite xml-ns . #p Identifiers without colon have an "empty prefix", but the canonical notation ":localname" is nevertheless not allowed. #p In every textual representation of a document, every prefix, including the empty prefix, must be mapped to a certain namespace URI. This namespace URI defines the "identity" of a certain namespace, i.e. is used for "equal()" tests. The assignments from prefices to URIs are valid in #emph!nested! scopes. In an textual representation of a document, such a scope is defined by the contents of an element (including its own name and the names of its attributes, see below). #p A special case is the empty URI "" which can only be represented by the empty prefix. #nl Per default, the empty prefix is mapped to the empty URI. #nl Further mappings are established (in the textual representation) using the following syntax, which looks like an attribute: #source ... #/source #p In this example, the empty prefix is mapped tu "uri1", the prefix #src!pref! to "uri2". This mapping is valid "backwards", already for the tag of the containing element! #p These assignments #emph!only look like! attributes, but are no attributes in the sense of SAX and DOM and tdom. #nl (FIXME says they ARE attributes, but FIXME says they are not!?) #p #source #/source #p Here the first assignmentis valid, the second NOT. #p The mapping of the empty prefix is ONLY VALID for element tags, not for attribute names. The latter stay with the empty URI iff they have an empty prefix. This table shows the allowed combinations: #table #border 1 #tr#td #td pref="" #td pref non-empty #tr#td uri="" #td ATT #td -- #tr#td #td EL #td -- #tr#td uri non-empty #td -- #td ATT #tr#td #td EL #td EL #/table #p An instance of our implementation, #link 4/util/NamespaceName.html#text NamespaceName#/link, represents all possible identifiers in an XML context, either in namespace mode or in non-namespace mode. #nl In namespace mode MUST have a local name and a (possibly empty) URI. #nl It MAY additionally have a prefix value. #p All field values are always != null. All arguments to a constructor call must be !=null ! "Not having" means being the empty string "". This corresponds to the requirements of SAX. #p Following combinations are possible, selected by different constructor signatures. #source URI localName prefix enableNameSpace new NamespaceName(uri,localname) "NONEMPTY" "NONEMPTY" "" true "" "NONEMPTY" "" true new NamespaceName(uri,prefix,localname) "NONEMPTY" "NONEMPTY" "NONEMPTY" true "" "NONEMPTY" "NONEMPTY" --> ERROR new NamespaceName(qname/localname) "" "::NON::EMPTY::" "" false ("NONEMPTY" does not contain colons!) #/source #p Only URI and localname are considered for the definition of "equals()"! As a consequence, non-namespace-names and namespace names in the no-uri-space are considered EQUAL iff they have the same local name! #p ( #nl The prefix is only used to memorize some previous external representation, for writing out the name with the same prefix again, #emph!iff possible!. It is only used for "ergonomic" reasons, but semantically not significant! When later serializing namespaces, it can serve as a MERE HINT for construting an external representation, resembling the originally read in. It is not really clean to keep it here, but the basic philosophy of namespace names is not ours. Anyhow, this partitioning is much less redundant and intermangled than the SAX "qnames", which contain the prefix and double the local name. #nl ) \\ ========================================================================= #h2 #title Namespaces in SAX #p The two kinds of SAX events which represent tags (startElement() and endElement()) have "uri", "localname" and "qName" as three independent arguments, e.g. to the "startElement()" method in #link 0/www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html #text ContentHandler#/link. #nl Its doc text says (not very clearly): #nl "If the #src!http://xml.org/sax/features/namespaces!-property is true (default!), then uri and localname must be provided. If false, both may together be there or may be not there. #nl If the #src!http://xml.org/sax/features/namespace-prefixes!-property is true then the qName is required. If false (default!) then it is optional." #nl To repeat: "not being there" always means being the empty string value, but not null! #p It is not clear in which mode which data takes which precedence! So, to be on the safe side, the all arguments should be supplied redundantly when using badly documented third-party software. Esp. "qname" should comply (redundantly) to the current mapping of prefices to uris. #p SAX includes the events #link 0/www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html #loc startPrefixMapping(java.lang.String,%20java.lang.String) #text startPrefixMapping(String,String)#/link and #link 0/www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html #loc endPrefixMapping(ava.lang.String) #text endPrefixMapping(String)#/link to grow and shrink this map. #nl It is NOT SPECIFIED what an "start" does when a prefix is already in use, and whether an "end" will let old, shadowed mappings pop-up again. #p OUR code which consumes SAX events treats these questions systematically and in a compositional way. #p The api doc of #link 0/www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html #loc startPrefixMapping(java.lang.String,%20java.lang.String) #text org.xml.sax.ContentHandler.startPrefixMapping(String,String)#/link says :#nl "There should never be start/endPrefixMapping events for the "xml" prefix, since it is predeclared and immutable." #p But all library functions which make up the SAX processing pipeline do #bold!not treat the "xml:" ns-prefix specially!. It is NOT YET CLEAR at which points, and how often, an explicit #source startPrefixMapping("xml", "http://www.w3.org/XML/1998/namespace") #/source #p is permitted, or even required! #nl FIXME !! #p It is also not yet clear how to avoid the following situation when translating from a less idiosyncratic model, e.g. writing out d2d "Udom" structures: #nl If a (non-empty) namespace-uri is assigned to the empty prefix, this is fine for all elements. But when later an ATTRIBUTE has to be written with this namespace-uri, then that must be matched to some non-empty prefix #emph additionally#/ to the empty one. #nl So in this case, "synonyms" seem really #emph necessary#/. #nl (( #nl Perhaps it would be the best strategy to leave the empty prefix immutably assigned to the empty URI, because the latter cannot be expressed in another way!?!? #nl And, even better, do never use the empty URI, if not required by some legacy format!? #nl )) #hr \\ ================================================================== #p Generally, our SAX processing pipelines operate in namespace mode. The value of "prefix" is normally ignored. But there are some applications in the outer world which #bold do require a certain prefix!#/bold In this context, the original prefix (eg. recognized by a third-party parser and communicated to a metatools internal structure involving NamespaceName instances, via a SAX event) can be stored in the "prefix" field of the NamespaceName instance. It then can be passed on transparently, and at last will be used on final re-serialization. BUT this only as a #bold!hint!, not carrying real semantics! #p The serialization of NamespaceName instances includes the emitting of the corrsponding "prefix mapping" events. In #mt, the serialization is performed by #link 4/util2/ContentPrinter.html#text ContentPrinter#/link. #nl But this device is NOT namespace-aware, it prints only q-names! So, for to use it in namespace mode, a #link 4/util2/NamespaceEmbedder.html#text NamespaceEmbedder#/link is pre-poned! This consumes the start/end mapping events, keeps track of all open scopes, and maps them to "PSEUDO-ATTRIBUTE" definitions. It fills in the resulting qName for all attributes and elements. This is of course an ABUSE of the SAX interface and does only work because the behaviour of our ContentPrinter is known and specified BEYOND the SAX convention! #nl (( #nl Consequently, in a first version, this code did remove the Uri and the local name from the sax events. But this DOES NOT WORK for Xalan Template Construction, see below, so for this case we have to produce redundant output! #nl )) #p Its code requires that there are NO HOMONYMS, ie. nested assignments of the same prefix to different (or the same?) uris. To ensure this, #link 4/util2/NamespaceHomonymResolver.html#text NamespaceHomonymResolver#/link can be included in the pipeline. #hr #p The #link 4/d2d2/base/Udom2Sax.html#text Udom2Sax-serializer#/link from d2d, eg, looks only whether the Uri of the namespaceName to write out next is already mapped to any prefix. If so, it does nothing! Only if not, a currently unused prefix is selected and assigned to this Uri. For this, the prefix stored in the namespace name is the first candidate. #p In #bold d2d#/ namespaces can be declared in genuine "ddf" definitions by prefix and ns-uri. Both must be non-empty. #nl In the "#src!with xmlrep element = !" part, the xml tag can have a prefix, which then will be mapped back to the declared namespace uri to construct a namespace name. #nl If there is no prefix in the xml tag, and no namespace has been declared to be "default" then, then a namespace name is constructed with empty prefix, mapped to the empty uri. Otherwise, the declared default is taken. #p If a #bold dtd is imported to d2d#/ as a definition module, then the "" namespace declarations are respected and required. #p The following graphic tries to summarize the situation between d2d output and ContentPrinter: #source STARTPREFIXMAPPING uuuu pppp STARTELEMENT uuuu llll ENDELEMENT uuuu llll ENDPREFIXMAPPING pppp ==================[namespaceEmbedder] ======== > STARTPREFIXMAPPING uuuu pppp STARTELEMENT uuuu llll pppp:llll ATTRIBUTE ---- pppp xmlns:pppp = uuuu ENDELEMENT uuuu llll pppp:llll ENDPREFIXMAPPING pppp //original intention of namespaceEmbedder, to be used with content printer, // was different, namely: ==================[namespaceEmbedder] ======== > STARTELEMENT ---- ---- pppp:llll ATTRIBUTE ---- ---- xmlns:pppp = uuuu ENDELEMENT ---- ---- pppp:llll #/source #p (( #nl The original design did NOT WORK when the sax events were piped into a JAXP-TemplateHandler receiver for constructing an XSLT Transformer. This SEEMS TO require the redundant version, as we found out after two days' reverse engineering !-( #nl )) \\ ========================================================================= #h2 #title Reserved Namespaces #p The most frequent reserved namespace is #source xmnls:xml="http://www.w3.org/XML/1998/namespace" #/source #p It is special in very different concerns, which make it hard to treat it consistently: #list #i The namespace uri "http://www.w3.org/XML/1998/namespace" is always bound to the prefix "xml:". #i This #emph!may! be declared, but #i it #emph!is not required! to be declared, ie. this mapping is always valid, implicitly. #i This namespace name must not be bound to a different prefix, and #i the the prefix "xml:" must not be bound to a different namespace name. #/list See [NS in XML:sect 3, last paras]. #p Esp. the last points are crucial, because our normal pipeline cannot treat this prefix and uri in the canonical way. Current firefox (36.0.1) indeed rejects documents which attempt this. VERY UGLY! \\ ========================================================================= #h1 #title XML Namespaces in D2d processing \\ ========================================================================= #p In the context of #ddd, there are some very different settings involving name spaces: #p #bold 1-- #p The fundamental taks of #ddd is to produce an XML encoded output from a "readable" #ddd source. This is described in #link d2d.html#/link in detail. A #link d2d.html#loc txt_namespace#text dedicated section#/link describes how name spaces are defined in the text type definition, and how element and attribute definitions can refer to name spaces (via prefices) when defining an explicit xml tag. #p #xemph 2-- #p When a DTD is used to define the text format and the parsing rules, then, for namespaces to be active, the tags(=element names/attribute names) in the DTD must have to the form with one colon ("#src!ab:cde!"), and there must be TDOM-PIs like "#src!!" in the DTD. The d2d parser will do as it alway does: accept (and need) only the pure "local" tags, like "#src!cde!", and generate the XML output in the intended name space. #p #xemph 3-- #p When a #ddd source text is used to describe an XSLT transformation, then the target format is given by the header: #nl #commandchar$ "$src!#d2d 2.0 xslt text producing! : " $commandchar# #nl By this the (zero to more) namespace declarations occuring in the target text type are known, i.e. the corresponding mappings of prefices to uris. The namespace declaration for xslt itself is known anyhow and uses some fixed prefix. #p But additional name spaces can be required, namely those occuring the #emph!input document!, to which the defined xslt code later shall be applied, or for calling some "tpath runtime extension functions", which can live in any name space. For this the xslt mode defines an additional syntax, see the #link d2d.html#loc txt_xslt_additional_namespaces#text dedicated section#/link in the d2d xslt mode documentation. #p#kind src These uri->prefix mappings can be retrieved by FIXME APIDOC Text2Udom.getXsltInputNamespaces() #p #xemph 4-- #p When the xslt rules are defined in the ddf text format definition (with "#src!docu to_!" constructs, as explained in #link d2d.html#loc txt_transformationrules#text the d2d documentation#/link), then the namespaces of the input document are known, because this is the #ddd model just created, and the target type is indicated by the "" in the transformation definition. #p All additional name spaces needed for tpath extension functions etc. can currently only be added by extending the namespace declaration mechanism: #xemph!All namespace declarations! of #xemph!all modules involved! will be combined into the namespace declarations of the synthesized xslt source. Of course this is not an optimal solution, because #xemph!conflicts of prefices must be "manually" avoided! in advance. #p (An automated solution is of course possible as soon as the xslt sources are parsed by ourself and not let to an external tool. But this is not the general case.) #p#kind src (There had been the concept of an additional txsl element "#src!tpathNamespace!" for this purpose, but this turned out to be too fine granular and ergonomically not good.) #p #xemph 5-- #p Sometimes a #ddd text type definition (ddf) is translated into a DTD. This is executed as a "Task" from the #ddd man tool, see #link d2d.html#loc txt_tool#text the tool doc.#/link #nl (This is frequently done to compile the DTD via #link tdom.html#text TDOM#/link into a strongly typed #java model.) #p In this case, the name spaces declarations from the ddf text type definition will re-appear as "#src!!" process instructions, as described above. \\ ========================================================================= #h1 #title Error Signalling and Processing \\ ========================================================================= #p#kind missing MORE TO COME \\ ========================================================================= #h2 #title General Strategies \\ ========================================================================= #p Errors and Exceptions can be treated by different mechanisms, depending on the usage context of the code, whether it is sensible to continue the operation of a certain module after the error, and depending on the size of the software module. #p #bold Small, low-level and general purpose#/ modules may signal an error by throwing an exception without any declaration, ie. a subclass of #link 5/java/lang/RuntimeException.html?is-external=true #text !/java.lang.RuntimeException#/link. With throwing an exception, the execution of the current method call is finished. So this is really a very limited protocol. #p Then some higher layer in the software architecture is responsible for translating this error into some diagnosis sensible for a user. An exception should NEVER reach the user's level. #p #bold Larger, specialized#/ software modules get a #link 4/message/MessageReceiver.html#text MessageReceiver#/link as a constructor parameter. They send warnings, errors and hints #emph!explicitly! to this channel. #p This can happen arbitrarily often, without terminating execution of the module's functionality. #p Additionally, a result may be set #src!==null! or to some other dedicated value, to indicate that the execution has failed and any pipeline processing cannot be continued without special reactions. #p The message receiver can "tee" the messages to a #link 4/message/MessageCounter.html#text MessageCounter#/link, for easily detecting if severe errors have occured in a transformation step. \\ ========================================================================= #h2 #title The ANTRL / xantlr / tdom / xantlrtdom Error Signalling Pipeline \\ ========================================================================= #p \\ #kind missing MORE TO COME \\ ========================================================================= #h2 #title Errors in SAX and JAXP/TRAX \\ ========================================================================= #p #link org.xml.sax.XMLReader#/link defines a method "setErrorHandler(org.xml.sax.ErrorHander)". #p Such an error handler must implement three methods, (warning(), error() and fatalError()), all parametrized with an SAXParseException object. #p #kind missing MORE TO COME #eof