cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

xpath equivalent of FOSI #CONTENT?

ptc-1908075
1-Newbie

xpath equivalent of FOSI #CONTENT?

What is thexpath equivalent of FOSI #CONTENT? I need to save an element's #PCDATA and any tags. Not PIs, although FOSI probably would ignore them.


The SGML doc has the following. Note that and <brk> are singletons.

<title>Lorem ipsum<brk>dolor sit amet</title>

In the FOSI, precedingsibling
is trying to save the <title> element's #CONTENT. The FOSI had the following, which worked until <br...




























24 REPLIES 24

Hi Suzanne--



Try this:



string(following-sibling::title[1])



That should give you all the text inside the title, including text
inside any child elements.



--Clay



Clay Helberg

Senior Consultant

TerraXML


Hi Clay!

This yields the text but not <brk>.

Suzanne


I don't think you can get what you want with this approach, due to what the
FOSI engine does with the result of the XPath expression (nothing to do
with XPath, itself). Each of your examples and the stated result is
consistent with the string value of the first node in the result being
used. You got closest with "following-sibling::title[1]" (or the version
without "[1]"), but since the string value is being taken, you'll never get
the <brk>.

I think (not tested) you might get what you want with:

<e-i-c gi="a">
...
<att>
<charsubset>
<savetext textid="title.txt" conrule="#XPATHCONTENT(&lt;br"/>following-sibling::title[1])#XPATH">
...

-Brandon 🙂


On Thu, Jul 12, 2012 at 5:41 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> What is the xpath equivalent of FOSI #CONTENT? I need to save an
> element's #PCDATA and any tags. Not PIs, although FOSI probably would
> ignore them.
>
> The SGML doc has the following. Note that and <brk> are singletons.
>
>
<title>Lorem ipsum<brk>dolor sit amet</title>
>
>
> In the FOSI, preceding sibling
is trying to save the <title>
> element's #CONTENT. The FOSI had the following, which worked until <...



























Hi Brandon!

I'll give it a try.

Thanks!
Suzanne


Hi Suzanne--



Ok, I had to go back and reread your original post. At first I thought
you wanted to capture some text content inside the child element, but I
see you actually want the child element markup. As Brandon pointed out,
the way FOSI is using XPath in this instance coerces it to a string,
which is why you are only getting text content and no markup.



My FOSI-fu is weak, so I don't really know the differences between the
different ways that FOSIs can invoke XPath. Brandon's suggested approach
may work. If not, you might have to consider replacing the XPath
approach with a pure FOSI variable approach, which I suspect you can
work out with both hands tied behind your back. 🙂



--Clay





Clay Helberg

Senior Consultant

TerraXML


Nothing gets saved with that.
Suzanne


Hi Suzzane,



You could try do this:

<savetext textid="title.txt"&lt;br"/>conrule="#XPATHNODESET(following-sibling::title[1])#XPATHNODESET">



Thanks and Regards,

Suresh.

On Fri, Jul 13, 2012 at 10:11 AM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Nothing gets saved with that.
> Suzanne
>

Hi Suzzane,

I was wrong.
it should have been.

#XPATHNODESET( following-sibling::title[1])#XPATH">

Thanks and Regards,
Suresh.

Hmm... I'm surprised you don't get anything. The next thing I'd try is
almost the same as Suresh's version, replacing "#XPATHCONTENT" with
"#XPATHNODESET", but adding a "/node()" to the XPath expression. That
should get you just the content of the "title" element, without the element
itself:

#XPATHNODESET(following-sibling::title[1]/node())#XPATH

-Brandon 🙂


On Thu, Jul 12, 2012 at 6:11 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Nothing gets saved with that.
> Suzanne
>

I tried#XPATHNODESET, but it didn't save anything either. I'm surprised, because I have examples in my book of#XPATHNODESET ad#XPATHCONTENT that return tags. However, this situation is different. In the book I am just trying to demonstrate the markup that FOSI will format.

I tried following-sibling::title[1][.], which saves the text but not the <brk>.

I wish I could do this with FOSI. An unusual combination of markup and formatting requirements has me stumped. However, writing this up got me thinking about something to look into with FOSI.

Thanks everyone!

Suzanne



>----------
>>

Thanks, but that didn't save anything.


I am surprised to know that it didn't work either.
In fact, the reference was taken from your book 🙂

On Fri, Jul 13, 2012 at 10:41 AM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Thanks, but that didn't save anything.
>

Methinks there's something strange going on with the document or some other
piece that is causing the XPath processing to fail in some way. Can you
try just #XPATH in the conrule, rather than #XPATHCONTENT or #XPATHNODESET?
With that, you should get comparable results to your fillval-based
approach, since it also takes the string-value of the result.

Make sure the closing part is ")#XPATH", no matter which version you use.
The description in 28001C.sgm omits the "#" in that part, which has
certainly tripped me up, at least once.

-Brandon 🙂


On Thu, Jul 12, 2012 at 6:39 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> I tried #XPATHNODESET, but it didn't save anything either. I'm surprised,
> because I have examples in my book of #XPATHNODESET ad #XPATHCONTENT that
> return tags. However, this situation is different. In the book I am just
> trying to demonstrate the markup that FOSI will format.
>
> I tried following-sibling::title[1][.], which saves the text but not the
> <brk>.
>
> I wish I could do this with FOSI. An unusual combination of markup and
> formatting requirements has me stumped. However, writing this up got me
> thinking about something to look into with FOSI.
>
> Thanks everyone!
>
> Suzanne
>
>

Just to follow up.It turns out some error messages are reported. Checking my book, I see #XPATHCONTENT, et al., are supported for savetext conrule and usetext source, but not fillval attname.

[A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282] Invalid XPath expression: The function '#XPATHCONTENT' was not found.

Element: icon. XPath expression: #XPATHCONTENT(following-sibling::title[1])#XPATH.

A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282] Invalid XPath expression: The function '#XPATHCONTENT' was not found.
Element: icon. XPath expression: #XPATHCONTENT(following-sibling::title[1])#XPATH.

[A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282] Invalid XPath expression: The function '#XPATH' was not found.
Element: icon. XPath expression: #XPATH(following-sibling::title[1])#XPATH.

So, if only for the sake of the archives, what happens if you get rid of
the fillval and put the #XPATHCONTENT directly in the conrule?

-Brandon 🙂


On Thu, Jul 12, 2012 at 8:45 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> Just to follow up. It turns out some error messages are reported.
> Checking my book, I see #XPATHCONTENT, et al., are supported for savetext
> conrule and usetext source, but not fillval attname.
>
> [A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282]
> Invalid XPath expression: The function '#XPATHCONTENT' was not found.
> Element: icon. XPath expression:
> #XPATHCONTENT(following-sibling::title[1])#XPATH.
>
> A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282]
> Invalid XPath expression: The function '#XPATHCONTENT' was not found.
> Element: icon. XPath expression:
> #XPATHCONTENT(following-sibling::title[1])#XPATH.
>
> [A31450] ERROR: Cannot evaluate XPath expression in stylesheet. [A30282]
> Invalid XPath expression: The function '#XPATH' was not found.
> Element: icon. XPath expression:
> #XPATH(following-sibling::title[1])#XPATH.
>

I haven't gotten to that yet. Something else came up. But I'll share whatever happens. I am also writing up the unusual circumstances that caused me to use xpath in the first place, and I'll share that, too. Then it will be in the archives, and I won't feel like I have to put it in the book. I finally have a finite list of things to be authored/edited for the book, and I am trying very hard not to add to the list.


When has content, the elements are not reordered and there's no problem. it's a case of the same markup doing double duty because the markup that's needed isn't available. The DTD forces a choice between two constructs when in fact both are needed. The authors were creative enough to find a way to capture the content for both using the same markup.


I wouldn't know about xpath, but what happens if you save to a TDV and then in <c> resave it to a TIV with placemnt="after"? (Put your "container" in an ATTR test for <c>).


gi="a"
<savetext textid=".b.tdv" conrule="" placemnt="before"">


gi="b"
<savetext textid=".b.tdv" conrule="#CONTENT">

gi="c"
<att> If is not empty:
<specval attname="b.tdv" attloc="#FOSI" attval="#ANY">
<savetext textid=".b.tiv" conrule="#CONTENT" append="0">


<att> If is empty do this:
<specval attname="b.tdv" attloc="#FOSI" attval="#NONE">
<do whatever=" is=" appropriate=">

If has a value it winds up in the TIV until reset by another occurrence of . You might set it up with a scope of <c>. I don't have time to actually play with this. I remembe...






The problem is there is no scoping element for b.tiv. It could be a pseudo-element, but must be in context of the same pseudo-element in order for<title> and to be output before .


Here's a tested-and-working version of what I initially proposed, using
XPath. The e-i-c for "a" does the rearranging, while the ones for "title"
and "b" just hide themselves, as appropriate.

<e-i-c gi="a">
<charlist inherit="1"></charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<specval attname="following-sibling::b[1][string(.)]"&lt;br"/>attloc="#xpath" attval="1">
<charsubset>
<usetext<br/>source="#XPATHCONTENT(following-sibling::b[1])#XPATH"
placemnt="before"></usetext>
<usetext<br/>source="#XPATHNODESET(following-sibling::title[1])#XPATH"
placemnt="before"></usetext>
</charsubset>
</att>
</e-i-c>

<e-i-c gi="title">
<charlist inherit="1">
<textbrk startln="0" endln="0"></charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<specval attname="following-sibling::b[1][string(.)]"&lt;br"/>attloc="#xpath" attval="1">
<charsubset>
<suppress sup="1"></charsubset>
</att>
</e-i-c>

<e-i-c gi="b">
<charlist inherit="1">
<textbrk startln="0" endln="0"></charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<charsubset>
<suppress sup="1"></charsubset>
</att>
</e-i-c>


Now, by "a FOSI way", I'm guessing you mean "without using XPath", so
here's that version. I assume an element called "abc" as the overall
container for all this content (there's got to be something, even if it's
the document element).

If we can't save the "a" element within its own e-i-c, we can save
everything from the parent and use a couple of counters to output the right
"a" in a pass through the parent's content on each "c", at which point
we'll know what was in "b". Separate text variables hold the content of
each "title" and "b" for later output. Because we don't know in advance if
we need to reorder or not, we basically end up doing it every time, even if
there's really no change in the case where "b" is empty.

First, the counters and variables. Note the initial="2" on one counter to
make things match up, due to the timing mismatch involved when we're
outputting at "c" the previous "a", with the counter being incremented by
"b" in between.

<counter initial="1" enumid="b.ct">
<counter initial="2" enumid="b-psu.ct">
<stringdecl textid="abc.txt">
<stringdecl textid="title.txt">
<stringdecl textid="b.txt">

And here are the e-i-cs. Note that the context="a.psu" e-i-cs are just
there to hide everything except the "a" we want on any given pass, based on
the "b.ct" counter. If anything else might show up inside the "abc"
element, additional e-i-cs of this type would be needed.

<e-i-c gi="abc">
<charlist>
<reset resetlist="b.ct">
<savetext textid="abc.txt"&lt;br"/>conrule="<a.psu>,#CONTENT,</a.psu>" placemnt="before">
<savetext textid="b.txt" conrule="\\" placemnt="before">
<savetext textid="title.txt" conrule="\\" placemnt="before"></charlist>
</e-i-c>

<e-i-c gi="a" context="abc">
<charlist inherit="1"></charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<charsubset>
<suppress sup="1"></charsubset>
</att>
</e-i-c>

<e-i-c gi="title" context="abc">
<charlist inherit="1">
<textbrk startln="0" endln="0">
<savetext textid="title.txt" conrule="#CONTENT" placemnt="before">
</charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<charsubset>
<suppress sup="1"></charsubset>
</att>
</e-i-c>

<e-i-c gi="b" context="abc">
<charlist inherit="1">
<textbrk startln="0" endln="0">
<enumerat increm="1" enumid="b.ct">
<savetext textid="b.txt" conrule="#CONTENT" placemnt="before">
</charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<charsubset>
<suppress sup="1"></charsubset>
</att>
</e-i-c>

<e-i-c gi="c" context="abc">
<charlist inherit="1">
<textbrk startln="0" endln="1"></charlist>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<specval attname="b.txt" attloc="#FOSI" attval="#ANY">
<charsubset>
<usetext source="b.txt" placemnt="before"></usetext>
<usetext source="title.txt" placemnt="before"></usetext>
<usetext source="abc.txt" placemnt="before"></usetext>
</charsubset>
</att>
<att>
<specval attname="PRINT-ONLY" attloc="system-var" attval="#ANY">
<specval attname="b.txt" attloc="#FOSI" attval="#NONE">
<charsubset>
<usetext source="abc.txt" placemnt="before"></usetext>
<usetext source="title.txt" placemnt="before"></usetext>
</charsubset>
</att>
</e-i-c>

<e-i-c gi="a.psu">
<charlist>
<reset resetlist="b-psu.ct"></charlist>
</e-i-c>

<e-i-c gi="a" context="a.psu">
<charlist>
<suppress sup="1"></charlist>
<att>
<specval attname="b-psu.ct" attloc="#FOSI" attval="#EQ#b.ct">
<charsubset>
<suppress sup="0"></charsubset>
</att>
</e-i-c>

<e-i-c gi="title" context="a.psu">
<charlist>
<suppress sup="1"></charlist>
</e-i-c>

<e-i-c gi="b" context="a.psu">
<charlist>
<suppress sup="1">
<enumerat increm="1" enumid="b-psu.ct"></charlist>
</e-i-c>

<e-i-c gi="c" context="a.psu">
<charlist>
<suppress sup="1"></charlist>
</e-i-c>

-Brandon 🙂


On Fri, Jul 13, 2012 at 5:16 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> In this particular case, the markup seems to be insufficient for FOSI to
> achieve the desired formatting. FOSI is best when there is a specific
> context for everything, which isn't the case here.
>
> The SGML doc has:
>
> <title>TTT</title>BBB<c>CCC</c>
>
<title>TTT</title>BBB<c>CCC</c>
>
...
>
> The formatting depends on whether element is empty or not. If has
> content, the output shoul...



, <title>, , and
> <c>, so there is no scope for a time-independent variable.
>
> Also,
is a singleton graphic, which means FOSI can't save 's
> graphic for output later. If
had a container (such as <figue> with
> <graphic>), savetext on the container e-i-c would save the g...



to get the content of
> <title> and . It was working until <brk> tags were inserted in <title>.
> Wha...








My apologies for the delay in following up on this.

I ended up using XPath. As soon as I consulted my book, I realized usetext was needed, as Brandon suggested.

Re: the FOSI approach, I tested the code Brandon provided and it worked. 🙂 I had been thinking about saving everything to a string and somehow using a counter to output the graphics one by one, but nothing specific was coming to me on the "somehow" part. Brandon's solution is perfect! It is such great stuff that I had to add it to my book. Note that Ifocused on the case when has content because it requires re-ordering the elements. Note that Brandon provided production-level code. The example in the book, however, tries to keep things short and sweet.

PDF is attached. All feedback is welcome.

Thanks!
Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"



Announcements