Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xsl] Processing IDREFS attributes

From: Dan Vint <dvint@--------->
To:
Date: 11/1/2005 10:36:00 PM
At 02:10 PM 11/1/2005, JBryant@xxxxxxxxx wrote:
Well, I think the folks who wrote the specs thought you'd pass one IDREF
at a time, rather than bunches of them. Also, I come from the school that
keeps each function as atomic as possible, so I'd rather have tokenize and
id be separate functions, since I'll undoubtedly use tokenize outside of
id someday.




Well the problem is in original XML I needed to list a string of IDs 
because it was a one to many relationship and attributes were the only way 
to go, so I have this list I need to process. As you indicated tokenize is 
now in v2, but there was no solution to work with them in v1.



My problem with the recursive template solution is now that it is in a 
template, and I need to do something to each value looked up, I have to 
have a unique template for each use of IDREFS. Maybe tokenize would work 
with the for-each better than the recursive template approach. I may have 
just found my reason to move forward.



..dan





Jay Bryant
Bryant Communication Services
(presently consulting at Synergistic Solution Technologies)






Dan Vint <dvint@xxxxxxxxx>
11/01/2005 04:03 PM
Please respond to
xsl-list@xxxxxxxxxxxxxxxxxxxxxx


To
xsl-list@xxxxxxxxxxxxxxxxxxxxxx
cc

Subject
Re: [xsl] Processing IDREFS attributes










thanks,



that was where I was going, but I'm surprised that a function was provided



to track down IDs but not one to pull apart IDREFS, or build that tokenize



functionality into the id() function itself.



I'm slowly building a list of reasons to move on to XLST 2, just lazy at
the moment I guess ;-)

..dan



At 01:46 PM 11/1/2005, you wrote:
>Hi, Dan,
>
>Assuming that "Location", "Party", and "Organization" are three different
>locations in your source file, you'll need either a recursive template
(if
>you use XSLT 1.0) or the tokenize function (if you use XSLT 2.0).
>
>If you do need a recursive template, it's a pretty simple one in this
>case:
>
><xsl:template name="process-ids">
>   <xsl:param name="in-string"/>
>   <xsl:choose>
>     <xsl:when test="contains($in-string, ' ')">
>       <!-- process an id here; substring-before($in-string, ' ') gets
the
>id string to process-->
>       <xsl:call-template name="process-ids">
>         <xsl:with-param name="in-string"
>select="substring-after($in-string, ' ')"/>
>       <xsl:call-template>
>     </xsl:when>
>     <xsl:otherwise>
>       <!-- process the last id here -->
>     <xsl:otherwise>
>   </xsl:choose>
></xsl:template>
>
>You'd call it with
>
><xsl:call-template name="process-ids">
>   <xsl:with-param name="in-string" select="@parameters"/>
></xsl:call-template>
>
>The XSLT 2.0 tokenize function is much less verbose:
>
><xsl:for-each select="tokenize(@references, ' ')">
>   <!-- process each id here; . gets the id string -->
></xsl:for-each>
>
>That's one of the reasons I like XSLT 2.0.
>
>Jay Bryant
>Bryant Communication Services
>(presently consulting at Synergistic Solution Technologies)
>
>
>
>
>Dan Vint <dvint@xxxxxxxxx>
>11/01/2005 03:00 PM
>Please respond to
>xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>
>
>To
>xsl-list@xxxxxxxxxxxxxxxxxxxxxx
>cc
>
>Subject
>[xsl] Processing IDREFS attributes
>
>
>
>
>
>
>I've got a few places where I have an attribute of type IDREFS and a
>sequence of ID values like references="Location Party Organization". I
had
>
>thought a simple for-each loop would pull these apart with the id()
>function, in something like this:
>
><xsl:for-each select="id(@references)">
>                  <xsl:value-of select="."/>
></xsl:for-each>
>
>But it doesn't work. What I get is the content of @references with the
>above.
>
>The only other solution I have thought about is creating a template and
>recursively pulling apart the string. This should work, but I would think
>there is a simpler way to make this work. Is there a solution I missed?
>
>..dan
>---------------------------------------------------------------------------
>Danny Vint
>
>Specializing in Panoramic Images of California and the West
>http://www.dvint.com
>
>voice: 510-522-4703
>
>When H.H. Bennett was asked why he preferred to be out
>shooting landscapes rather than spending time in his portrait studio:
>
>"It is easier to pose nature and less trouble to please."
>
>http://www.portalwisconsin.org/bennett_feature.cfm

---------------------------------------------------------------------------
Danny Vint

Specializing in Panoramic Images of California and the West
http://www.dvint.com

voice: 510-522-4703



When H.H. Bennett was asked why he preferred to be out
shooting landscapes rather than spending time in his portrait studio:

"It is easier to pose nature and less trouble to please."



http://www.portalwisconsin.org/bennett_feature.cfm

---------------------------------------------------------------------------
Danny Vint

Specializing in Panoramic Images of California and the West
http://www.dvint.com

voice: 510-522-4703



When H.H. Bennett was asked why he preferred to be out
shooting landscapes rather than spending time in his portrait studio:

"It is easier to pose nature and less trouble to please."



http://www.portalwisconsin.org/bennett_feature.cfm


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent