Literal Nodes

[Greg Esres]

<One>
This is a test
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
</One

When I process a "Two" node, I need to see if there is a text line
above it, as "This is a test" in the above example. I can't figure
out how to get access to that node. Suggestions?

Thanks!

 

[Joe Kesselman]

When I process a "Two" node, I need to see if there is a text line
above it, as "This is a test" in the above example. I can't figure
out how to get access to that node. Suggestions?

You haven't told us how you're processing the nodes. As a DOM? As a SAX
stream? Using XPath/XSLT? Other?

In the document you've shown us, every <Two> element is preceded by a
text node. Most of them are just whitespace (line break and
indentation); one of them has more than that. Navigating the document
tree to the previous sibling (or doing a bit of buffering, if you're
doing SAX programming) and checking whether the value contains
non-whitespace (or contains more than one line break, or whatever
criterion make sense for your application) should be straightforward.

 

[Pavel Lepin]

<One>
This is a test
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
</One

When I process a "Two" node, I need to see if there is a
text line above it

preceding-sibling::text()

 

[Peter Flynn]

<One>
This is a test
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
</One

Don't ever do this. It will only end in tears and recriminations. Unless
you really know what you are doing with text-document markup, put your
free-floating text inside some markup, eg

<One>
<Description>This is a test</Description>
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
<Two>Some Stuff</Two>
</One>

If what you showed is is stuff you've been sent, send it back and
suggest they get someone to mark it up sensibly before you process it.

When I process a "Two" node, I need to see if there is a text line
above it, as "This is a test" in the above example. I can't figure
out how to get access to that node. Suggestions?

preceding-sibling::text()[.!='']

///Peter

 

[Greg Esres]

<<You haven't told us how you're processing the nodes. As a DOM? As a
SAX
stream? Using XPath/XSLT? Other?>>>

Oh, sorry, I've got my mind so wrapped in XSLT that it never occurred
to me that it could be something else.

<<should be straightforward.>>

Yes. I was pretty sure that I tried "previous-sibling" but it didn't
work. Since you all seem to think that's the proper way, I must have
been doing something else wrong. I'll give it another shot. Thank
you.

 

[Greg Esres]

<<preceding-sibling::text()>>

I thought I had tried that. I had about decided that "siblings" were
only of the same node type. I'll try again, thanks.

 

[Greg Esres]

Peter Flynn wrote:

<<Don't ever do this. It will only end in tears and recriminations.
Unless
you really know what you are doing with text-document markup, put your
free-floating text inside some markup, eg>>

Argh, that seems impractical....the node is essentially all text, with
markup on only a few sections (in theory). Surely you wouldn't find
anything wrong with this HTML:

<div>
This is a bunch of "free floating text" followed by <b>something</
b> in bold that is just a
short section.
</div>

I don't see a fundamental difference between that and mine. (I'm
willing to learn, though, if you care to explain further.)

<<If what you showed is is stuff you've been sent, send it back and
suggest they get someone to mark it up sensibly before you process
it.>>

Sorry, it's my own. ;-) However, in the real life application, the
free floating texts is several paragraphs of text, interspersed with
other markup items.

 

[Joe Kesselman]

<<Don't ever do this. It will only end in tears and recriminations.
Unless
you really know what you are doing with text-document markup, put your
free-floating text inside some markup, eg>>

Argh, that seems impractical....

I agree that "don't ever do this" is overstated at best.

There are two approaches to using XML. One is very much data-oriented,
and for that the advice to give text its own elements may make sense.
(Or may not, depending on exactly what you're trying to represent.) The
other is text-document-oriented -- which is where XML, HTML, and SGML
started -- and does want to intermix text and markup.

XML, and XML tools, will handle either. The document-oriented approach
is sometimes a bit more work because -- obviously -- text nodes don't
have names, and because they force you to think about whether whitespace
is or isn't meaningful... and, in SAX, because you have to be aware of
buffering effects. But that doesn't make it wrong, just different.

 

[Joe Kesselman]

<<preceding-sibling::text()>>

I thought I had tried that. I had about decided that "siblings" were
only of the same node type. I'll try again, thanks.

Siblings are other children of the same parent, which means they can be
anything but attributes (depending on the context you're starting from).
Type constraints are imposed explicitly by whatever follows the axis
specifier -- in this example, text().

Note that the expression given above finds all text nodes before this
one. If you want the nearest preceding text node, that would be
preceding-sibling::text()[1]. If you want the preceding node if and only
if it is a text node, one way to say that would be
preceding-sibling::node()[1][self::text()]

XSLT's a programming language. If you want robust results, you need to
know exactly what you're going to see as input, describe exactly what
you want to retrieve from it, or (preferably) both.