xsl-list
[Top] [All Lists]

Re: [xsl] attribute value templates in elements fetched from a map?

2020-09-03 10:55:36
Am 03.09.2020 um 16:24 schrieb Graydon graydon(_at_)marost(_dot_)ca:
On Wed, Sep 02, 2020 at 10:27:17PM -0000, Martin Honnen 
martin(_dot_)honnen(_at_)gmx(_dot_)de scripsit:
I don't understand where you use xsl:evaluate and where you bind the
value to $calculated.

Let me try to give less ambiguous context!

I've got a few hundred source elements; these group into a small number of 
structural categories.  (block, table, inline, link, etc.)  That happens via 
map lookup:

<xsl:template match="*[$categoryMap(name()) = 'block']>
...structure markup goes here....
...something has to define the style...
</xsl:template>

That part works.

Inside the structure markup, there's an element that defines the rendering 
style.  There are many more rendering styles than there are structures, but 
many fewer than input element names; perhaps a hundred.  The rendering style is 
usually but not always a simple mapping between the element name and a style 
name, and I could -- for at least 80% of the cases -- store that in the same 
map as element markup if I went from

map(xs:string,xs:string)
to
map(xs:string,map(xs:string,item())

So the grouping templates would use

<xsl:template match="*[$categoryMap(name())('groupname') = 'block']>
....
</xsl:template>

and the style would use
<xsl:sequence select="$categoryMap(name())('style')"/>

and retrieve the style markup appropriate to this input element name.

This is attractive because I could keep all the details in the map, making long 
term maintenance simpler; the templates and the logic are stable and behaviour 
gets driven from the map, making it easy to add new elements or change a style.

The problem is that it isn't always a static style; sometimes other information that 
depends on the input element context is required, such as title depth. (title depth = 
"how many of my ancestors have titles?") This means there's extra/different 
markup in the style definition and a value that isn't statically derived from the element 
name. What I want to do is to store the style markup in the map in the same way, and 
populate it with the specific values somehow after I retrieve it.

So far,
- anonymous functions are an awkward and doubtful way to create nested
   elements in the result tree; might as well just call a regular XSLT
   function directly and encapsulate the source-element-to-style mapping
   in that function
- evaluate doesn't get me anything because I can xsl:evaluate XPath, but
   not markup, so this isn't a way to process the elements retrieved from
   the map to populate values
- there isn't any way (that I know of) to say "plunk this block of
   markup into the evaluation context like we called xsl:call-template
   and this markup retrieved from the map is what was in the template we
   called"
- there isn't any way (that I know of) to put an attribute value
   template in the element markup in the map and have it evaluated at
   retrieval time.

What I want to know is if I'm missing something, and there's a way to get 
element markup back out of a map and put it into evaluation context without 
having to use transform() and start a whole new process and pass in the whole 
input document for context anyway.

I haven't completely understood it but the third point sounds like you
need fn:transform on dynamically constructed or retrieved code. I know
you ruled that out in your initial post but I am not sure there is a
simpler way.

--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>