Package eu.bandm.tools.tdom.runtime
Class TypedEthereal
java.lang.Object
eu.bandm.tools.tdom.runtime.TypedNode
eu.bandm.tools.tdom.runtime.TypedEthereal
- Direct Known Subclasses:
TypedComment,TypedProcessingInstruction
Common superclass for free floating, ubiquituous and syntactically unconstrained
model components, namels comments and processing instructions.
The
Every substantial can be preceded by ethereals, and ethereals may follow. These are modelled by
Generalisation of the case of empty elements leads to the fact that every element and every document may have "leading" and "trailing" ethereals, before the first content component, and after the last. In tdom this is realized by
Neither XML nor Tdom do impose any theory on the relations between substantials and ethereals. It is up to the user to define that e.g. Comments are related to the immediately following substantial, or sim.
Tdom does not impose any preference about storing. Writing out the content of an element is done in this order:
When parsing , the place of storing is undefined. So the following variants are (a priori) totally equivalent:
TypedSubstantials (elements and pcdata)
make the skeleton of a tdom model instance and their appearance is constrained
by content models.
Between these, the ethereals may float freely.
Every substantial can be preceded by ethereals, and ethereals may follow. These are modelled by
TypedSubstantial.getPrecedingEthereals(),
TypedSubstantial.getFollowingEthereals(), etc.
Generalisation of the case of empty elements leads to the fact that every element and every document may have "leading" and "trailing" ethereals, before the first content component, and after the last. In tdom this is realized by
TypedElement.getEtherealContainer().
Neither XML nor Tdom do impose any theory on the relations between substantials and ethereals. It is up to the user to define that e.g. Comments are related to the immediately following substantial, or sim.
Tdom does not impose any preference about storing. Writing out the content of an element is done in this order:
- The open tag of the element,
- then its leading ethereals;
- then for every contained Substantial (element or pcdata) the preceding ethereals, its contents (pcdata or an element, recursively), and then the following ethereals;
- finally the trailing ethereals of e, followed by its close tag.
When parsing , the place of storing is undefined. So the following variants are (a priori) totally equivalent:
[x]
aComment --stored-as--> x.leading[0] or x.leading[0] or y.preceding[0]
aPI --stored-as--> x.leading[1] y.preceding[0] y.preceding[1]
[y/]
[/x]
A "normalizing rewriter" can move all Ethereals into some preferred positions.
E.g. all can be stored as "preceding" whenever possible, otherweise as
"leading". Such a transformation can be defined on UntypedVisitor. FIXME DOIT-
Nested Class Summary
Nested classes/interfaces inherited from class eu.bandm.tools.tdom.runtime.TypedNode
TypedNode.ParseListener<E extends TypedElement<?,?>> -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionabstract voiddump(ContentHandler contentHandler, LexicalHandler lexicalHandler) Write this model component to a SAX output stream.final TypedNode<?> Methods inherited from class eu.bandm.tools.tdom.runtime.TypedNode
asBigDecimal, asBigDecimal, asBigDecimal, asBigDecimal, asBigInteger, asBigInteger, asBigInteger, asBigInteger, asBoolean, asBoolean, asDouble, asDouble, asDouble, asDouble, asFloat, asFloat, asFloat, asFloat, asHexInt, asHexInt, asHexInt, asHexInt, asInt, asInt, asInt, asInt, asLong, asLong, asLong, asLong, asTrimmedString, asTrimmedString, asTrimmedString, asTrimmedString, checkPlus, checkPlus, checkStar, checkStar, checkStrict, encode, encode, encodeOptional, encodePlus, encodePlus, encodeStar, encodeStar, extractEthereals, getLocation, getPCData, setLocation, setLocation, setLocation
-
Constructor Details
-
TypedEthereal
protected TypedEthereal()
-
-
Method Details
-
dump
public abstract void dump(ContentHandler contentHandler, @Opt LexicalHandler lexicalHandler) throws SAXException Write this model component to a SAX output stream. Please note that in the SAX architecture, PIs are treated by aContentHandler, but Comments by aLexicalHandler, so these two handlers must be supplied as a tandem for a method defined with this abstract class.- Parameters:
contentHandler- (never null) SAX handler for writing a TypedProcessingInstructionlexicalHandler- SAX handler for writing a Comment. If null, then the comments are silently discarded.- Throws:
SAXException
-
forAnyExtension
-