Skip to main content
P
ptc-19080751-Visitor
1-Visitor
July 12, 2012
Question

xpath equivalent of FOSI #CONTENT?

  • July 12, 2012
  • 24 replies
  • 4871 views
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 <brk> was added to the title:

<e-i-c gi="a">
>...
><att>
><fillval attname="following-sibling::title[1]/text()" attloc="#XPATH"fillcat="savetext" fillchar="conrule"/">
><charsubset>
><savetext textid="title.txt">
>...
>
>
When <brk> is added in the title, #PCDATA is captured up to but not including the <brk> tag.

Here is what I've tried, and the results:

following-sibling::title[1]/text() captures the content up to but not including the <brk> tag.

following-sibling::title[1]/node() ditto.

following-sibling::title[1] saves all the #PCDATA but not <brk>.
following-sibling::title ditto

following-sibling::title[1]/string() savesnothing.


Thanks for any ideas!

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

    24 replies

    Show previous replies
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    July 12, 2012
    Thanks, but that didn't save anything.


    S
    sureshmaddela1-Visitor
    1-Visitor
    July 12, 2012
    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.
    >
    B
    bibach1-Visitor
    1-Visitor
    July 12, 2012
    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
    >
    >
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    July 13, 2012
    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.
    B
    bibach1-Visitor
    1-Visitor
    July 13, 2012
    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.
    >
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    July 13, 2012
    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.


    B
    bibach1-Visitor
    1-Visitor
    July 13, 2012
    So, you said what the output should be if has content (I'm assuming the
    "GRAPHIC" is the one referenced by ), but not what the output should be
    if is empty.

    -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 should be:
    >
    > BBB TTT GRAPHIC CCC
    >
    > There is no container tag for the repeating markup     , <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 graphic for
    > output later. Using a pseudo-element for a container for the graphic
    > element doesn't work.
    >
    > So I am resorting to xpath in the e-i-c for     to get the content of
    > <title> and . It was working until <brk> tags were inserted in <title>.
    > What is needed for the xpath is the equivalent of FOSI #CONTENT to save
    > #PCDATA and any tags. I still have some things to try with that approach.
    >
    > On the other hand, if anyone can figure out a FOSI way to do this, I'll
    > definitely put you and it in my book!
    >
    > Thanks!
    > Suzanne
    >
    >
    P
    ptc-19080751-VisitorAuthor
    1-Visitor
    July 13, 2012
    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.


    Show more replies
    Terms & ConditionsAccessibility statement