Skip to main content
E
ebenton1-Visitor
1-Visitor
May 19, 2010
Question

FOSI wild-card use

  • May 19, 2010
  • 8 replies
  • 1681 views
I know that you can use the wild-card character (*) in the context attribute of a FOSI e-i-c, such as context="para * chapter", which would mean a <para> within a <chapter> with any other elements in-between.
However, I would like to know if there is a way to use a wild-card to describe all elements with a certain suffix. We have dozens of container elements which can contain this inline element, and whose names all end in the suffix "-xxx-yyy".
Let's say we have an e-i-c for an element called "inline" (<inline>). If this element occurs within the context of any of the elements whose name ends with the "-xxx-yyy" suffix, it always needs to be formatted a certain way, which is different from the formatting in other contexts.
I would like to use something like <e-i-c gi="inline" context="*-xxx-yyy">, which I know will not work because of the default FOSI wild-card (*) character.

Is there another way to write this without listing all of the dozens of "-xxx-yyy" element names in the context attribute or making a separate e-i-c for each of the dozens of possibilities?

I suspect that there is no way to do this in FOSI without using some ACL or maybe XPath, but I thought I would ask to see if anyone knows of a better way.

    8 replies

    C
    ClayHelberg18-Opal
    18-Opal
    May 19, 2010
    Hi Ed-



    Just a thought: could you use a FOSI variable to manage this? In each of
    the *-xxx-yyy element EIC's, set the variable value to 1 when you enter
    and back to 0 when you exit. Then in your inline EIC, test the value of
    that variable.



    If that doesn't work, XPath should be able to help you out, as would an
    ACL system-func.



    --Clay


    E
    ebenton1-VisitorAuthor
    1-Visitor
    May 19, 2010
    Yeah, that probably would work. However, I was hoping to avoid modifying dozens of e-i-c's and/or creating dozens of new ones. I counted approximately 213 elements ending in "xxx-yyy", most of which can contain the <inline> element.
    It looks like we will probably go the ACL route.
    N
    naglists1-Visitor
    1-Visitor
    May 19, 2010
    Be careful with context checking system-funcs. I'm not 100% sure, but I seem
    to recall discovering a geometric performance problem with them. (I know I
    ran into that with some sort of system-func.)

    C
    ClayHelberg18-Opal
    18-Opal
    May 19, 2010
    Agreed. If you have too many *-xxx-yyy EIC's to make the variable
    approach practical, I would think XPath would be the next best option.
    You would probably use something like this:



    <e-i-c gi="inline" xpath="ancestor::*[contains(name(),'-xxx-yyy')]" &quot;=">

    ...

    </e-i-c>



    --Clay


    L
    LynnHales1-Visitor
    1-Visitor
    May 19, 2010
    Ed,

    Programmaticly would probably be the best way to do this. Unless the "-xxx-yyy" elements all are children of a common parent. Then maybe you could make the wild card go 'inline * -xxx-yyy-parent'.

    Another option might be to have multiple <inline> e-i-c's with the context for the exceptions set (given there aren't that many exceptions).

    Lynn


    ---- Paul Nagai <-> wrote:
    > Be careful with context checking system-funcs. I'm not 100% sure, but I seem
    > to recall discovering a geometric performance problem with them. (I know I
    > ran into that with some sort of system-func.)
    >
    >
    E
    ebenton1-VisitorAuthor
    1-Visitor
    May 20, 2010
    That looks pretty cool, but I don't think that my version of Editor (5.2) supports the xpath attribute on e-i-c's very well. Editor complains when I open an XML file using the FOSI with this <e-i-c> in it. I tried it in 5.4, but if you use xpath on any e-i-c's you have to change the FOSI <rsrcdesc> element eicorderispriority attribute from "0" (the default) to "1". This causes Editor to open the file with no complaints, but I haven't actually tried any formatting changes yet. I don't know what affect the eicorderispriority attribute would have on all our other formatting, so I hesitate to use this. Looks like we are back to using ACL.
    C
    ClayHelberg18-Opal
    18-Opal
    May 20, 2010
    Hi Ed-



    Right, I forgot about that eicorderispriority thing. If you don't
    already have that set on, it certainly makes sense to think twice before
    switching it. And if you are still on 5.2, that rules out that approach
    anyway.



    ACL should work OK, as long as you can make the code efficient enough to
    avoid bogging down the composition process. Do you have scads and scads
    of these instances in your documents, or are they somewhat rare?



    --Clay


    E
    ebenton1-VisitorAuthor
    1-Visitor
    May 20, 2010
    The cases of this happening are relatively rare, mostly involving older document instances. So I think using ACL should be OK. We are planning to upgrade to 5.4 at some indeterminate near-future date, so it irritates me even more that I can't use much, if any, xpath in the FOSI now, but will be able to later. Maybe I will make the e-I-c now, but enclose it within comment markup for future use.
    Terms & ConditionsAccessibility statement