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

Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X

FOSI wild-card use

ebenton
1-Newbie

FOSI wild-card use

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 8

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


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.

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.)

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


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.)
>
>

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.

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


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.
Top Tags