[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] Using PIs to set attributes


Subject: RE: [xsl] Using PIs to set attributes
From: "Steven Anderson" <sanderson@xxxxxxxxxxxxxx>
Date: Thu, 8 Jun 2006 14:15:30 -0700

Sara Mitchell is having a hard time posting to the list, so she asked me
to post this reply for her.

	Steve

-----Original Message-----
From: Mitchell, Sara
Sent: Thursday, June 08, 2006 10:46 AM
To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx'
Subject: RE: [xsl] Using PIs to set attributes

[Apologies up front -- some of this reply is FrameMaker-specific and not
related to XSLT.]

You're not the only one! Three points that I can help with (as I'm
working on this same problem):

* There isn't any reliable way in XSLT to handle the start-PI/end-PI
pair
  not enclosing a well balanced set of nodes (i.e., fully enclosing text
and
  elements). Either you post-process the XML with some other language
(maybe
  Perl? Or something that processes text one character at a time?) or
your
  users must apply manual fixes in FrameMaker! If they remove the
  conditional text in Structured Frame, reselect the content and reapply
the
  condition, FrameMaker enforces selection of well-balanced nodes. More
than
  likely the conditions were set in unstructured Frame files which were
  converted to structured -- this is at least what my situation is.

* It may be easier, if users are going to fix the FrameMaker source, to
  have them apply the attributes values instead. I have found a
FrameMaker
  plug-in, called Sourcerer, that provides "conditional text" like
behaviour
  based on setting attributes. It seems to work okay and gets the users
to
  start doing things the XML way. Also ask in some of the FrameMaker
groups
  in Yahoo -- there's a lot of people who know how to work with
FrameMaker
  to get better output.

* It is possible, once the start/end conditions select well balanced
  content, to find them. I don't have all the logic worked out (we're
trying
  Sourcerer as an easier solution), but the pseudo logic I had
tentatively
  mapped out looks something like this:

	<xsl:template match="processing-instruction('FM')">
		* if contains 'CondStart'
			* capture the condition name
			* select all sibling nodes and process first-one
in a re
			  Recursive call:
				* if current sibling is not a
processing-instruction('FM'),
	 				  Copy and set attribute value
				* if sibling is
processing-instruction('FM') check
					For 'CondEnd' and condition
name, copy if
					Not. If it is abandon list of
siblings and no
					More recursive calls
			* Find first sibling after 'CondEnd' and begin
normal
			  Processing from here.
	</xsl:template>

  This needs lots of work, hope it helps. Sara


-----Original Message-----
From: Steven Anderson [mailto:sanderson@xxxxxxxxxxxxxx]
Sent: Wednesday, June 07, 2006 11:31 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: [xsl] Using PIs to set attributes

I've got some XML that looks like this:

<p>Programmatic access to objects is determined by the objects that are
  <ul><?Fm Condstart API_Only?>
    <li>defined in your enterprise WSDL file</li>
    <li><?Fm Condend API_Only?><?Fm Condstart OT_Only?>
          available in the EntityNames[] array in the Session3 object
          <?Fm Condend OT_Only?></li>
    <li>in your organization configuration</li>
    <li>valid with your security access  ....

The processing instructions are designed to indicate conditional text
(if API is the target, include the content between the <?Fm Condstart
API_Only?> and  <?Fm Condend API_Only?>).

I'd like to process this XML and be able to replace it with something
like this:

<p>Programmatic access to objects is determined by the objects that are
  <ul>
    <li platform="api">defined in your enterprise WSDL file</li>
    <li><ph platform="ot">available in the EntityNames[] array
           in the Session3 object</ph></li>
    <li>in your organization configuration</li>
    <li>valid with your security access  ....

I'm really not sure how to do this.  These PIs are ill-behaved, crossing
element boundaries, can be nested, and can cross each other's boundaries
as well.  In other words, you could also see this:

<p>Programmatic access to objects is determined by the objects that are
  <ul><?Fm Condstart API_Only?>
    <li>defined in your enterprise WSDL file</li>
    <li><?Fm Condstart OT_Only?><?Fm Condend API_Only?>
          available in the EntityNames[] array in the Session3 object
          <?Fm Condend OT_Only?></li>
    <li>in your organization configuration</li>
    <li>valid with your security access  ....

Notice how OT_Only starts before API_Only ends?  I'm stumped, so any
advice would be greatly appreciated.

      Steve


Current Thread
Keywords