Skip to main content
L
LynnHales1-Visitor
1-Visitor
September 11, 2012
Question

Epic and XSL-FO

  • September 11, 2012
  • 12 replies
  • 4440 views
I am having some issues with Epic and some XSL-FO I work with.

I want to use Editor to make changes to the FO, but I continually get errors
that I do not get with processors like XML Spy or Oxygen. The first problem
I have is that when I try to add FO elements, they are not listed in the
insert markup box(es). Next Epic does not seem to like <xsl:include>. It
will read them when publishing, but not when editing.

I have validated this by commenting out all the "includes" in my main file
and replacing them with ENTITIES. The errors I get change, presenting a
couple I know are in the referenced files.

Lastly, does anyone know what parser Epic uses to validate XSL files? I get
errors with Epic that I do not see with Spy or Oxygen.

Right now, though I love Epic as an XML editor, I have less than kind terms
to use for its support of XSL.


Lynn

    12 replies

    C
    ClayHelberg18-Opal
    18-Opal
    September 11, 2012
    Hi Lynn--

    I don't think Arbortext was ever intended for use as an XSL editor. The
    main issue is this: XSLT is basically an incomplete doctype fragment.
    Because XSLT can be used to transform any kind of XML into any other
    kind of XML (or into text or HTML), it would literally be impossible to
    know what literal elements (as opposed to xsl namespace elements) should
    be available for insertion. Consider that <xsl:for-each> would need to
    allow essentially any FO element as a child, and you would need to allow
    this inside almost every FO element. So basically your quicktags menu
    would have to include all XSLT elements and all FO elements in most
    circumstances. So the benefit of the quicktags menu would be minimal at
    best.

    My advice would be to use a specialized tool for XSLT/XSL-FO editing.
    jEdit has a good XSLT mode, and I've heard good things about Oxygen,
    though I haven't personally used it.

    The XSLT processor in Arbortext is Saxon, which is more or less the
    industry standard, written by Michael Kay, one of the major contributors
    to and chair of (IIRC) the W3C spec committee, and is one of the few
    engines that supports XSLT 2.0. If you prefer the Xalan processor, you
    can change the configuration to use that engine instead by modifying
    xsl.ccf.

    --Clay

    Clay Helberg
    Senior Consultant
    TerraXML

    T
    thendricks12-Amethyst
    12-Amethyst
    September 11, 2012
    I agree with Clay. I've been using jedit specifically for a few years now and recommend it regularly. Beyond the built in xsl assist it also has add-ins that do other handy xml tasks such as auto-indentation which can be quite handy.


    Trevor Hendricks
    Project Analyst -- Publication Systems
    Kohler Co.


    G
    GarethOakes16-Pearl
    16-Pearl
    September 12, 2012
    oXygen user here. It can even debug XSLT which comes in handy...

    -G
    L
    lfraley1-Visitor
    1-Visitor
    September 12, 2012
    I'm an oXygener too.

    L
    LynnHales1-VisitorAuthor
    1-Visitor
    September 12, 2012
    I like Oxygen, it is a nice, fairly inexpensive tool. I had to do some
    internal documentation to a schema last month. I used Spy for the input and
    Oxygen for the output file. Much better than what Spy did.

    Lynn
    S
    SindyYoung1-Visitor
    1-Visitor
    September 12, 2012
    Ok Adepters, here is my issue. I am working with Arbortext 5.4 M70. I have an sgml file that has a change tag with the attribute of Mark = "1", the default value is "0". The value of "1" tells the publishing application to put a change bar in the margins, (i,e, paper/PDF publications)

    When I open this file up in Arbortext, the attribute does not show up until I go in and reset it. Is there a "setting" in Arbortext that I am not aware of to make these change tags show up the way they should.



    Below is the before and after pics of what is happening.



    [cid:image001.png@01CD90E2.EAA7B340][cid:image002.png@01CD90E2.EAA7B340]

    This is the way it shows up when the file is opened.



    [cid:image007.png@01CD90E6.428B5DC0]You will notice the Mark attribute is set in the dialog box,

    But doesn't show up in the file;

    [cid:image003.png@01CD90E3.4B672800]



    If I go in and delete the attribute value and re-populate it

    Then this happens;

    [cid:image005.png@01CD90E3.C118DB20][cid:image004.png@01CD90E3.4B672800]Notice the "mark" text has turned blue to show that a value has been set.



    [cid:image006.png@01CD90E3.C118DB20] Now the attribute shows up in the change tag as it should.
    S
    SindyYoung1-Visitor
    1-Visitor
    September 12, 2012


    Ok I seem to be on a roll today.

    I have an sgml file that appends a -1 to the end of a graphic boardno.

    The best that I can figure is that once a graphic has been inserted into the file, it lists it in the graphic entities, if the graphic is re-inserted into the file is when it adds the -1, -2 to the end of the boardno. This happens even if the graphic is physically not in the file but is listed in the graphics folder.
    L
    LynnHales1-VisitorAuthor
    1-Visitor
    September 12, 2012
    Sindy,



    That is strange, but the first thing I noticed is that the 'mark' attribute
    is not showing up as blue. When an attribute is set that is other than the
    default value, the attribute name changes to blue. With an SGML document,
    attributes listed in the DTD are not required to show up in the start tag.



    So what is happening, is Epic is reading this as a manually set value. One
    thing to do is when you initially open the file run this from the command
    line.

    eval oid_attr(oid_current_tag(), mark)



    If Epic is reading it, it should show up as "1". If not, then it should
    appear as the default of "0". I'd also double check the DTD to make sure no
    one has changed the default value. You can verify this with the following



    Eval tag_attr_default(change, mark)



    I thought at one time there was a set command that would do what you want,
    but I didn't see it. You may want to open up the help center and go through
    the set commands list and see if I missed anything.



    Another place to check would be your dcf file.



    Lynn


    L
    LynnHales1-VisitorAuthor
    1-Visitor
    September 12, 2012
    Sindy,



    Shoot this is going to be fun to ask. When Epic adds the -# is it by the
    'boardno' or by the <graphic>? I guess is there a boardno='a-1' and a
    boardno='b-1' or would it be boardno='a-1' followed by boardno='b-2' (with
    no b-1). Not sure what would be causing the problem, but that might help
    find a bug if that is what it is.



    The next question is, does Epic find the graphic with the new boardno?



    Lynn


    S
    SindyYoung1-Visitor
    1-Visitor
    September 12, 2012
    Lynn,
    It is adding it to the end of the boardno.
    For example <figure><graphic boardno="abc123"></graphic></figure>
    There are occasions when we open the file that the graphic viewer (IsoView) does not display the graphic. When this happens you have to put the graphic back it. When you do it will do this is what happens <figure><graphic boardno="abc123-1"></graphic></figure>. It doesn't matter if you map directly to the location of the graphic or if you drag and drop the graphic into the file.
    The only way to get it to NOT do it is to delete the original graphic tag and reinsert it.
    As some of our documents are quite large, my authors are balking at this added step.
    Sindy
    Show more replies
    Terms & ConditionsAccessibility statement