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

Subject: Re: [xsl] attribute value templates in elements fetched from a map?
From: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 3 Sep 2020 15:43:03 -0000
>  Is that a bit less like nonsense?

I personally still don't understand the problem...

A simple, complete example may be helpful.


On Thu, Sep 3, 2020 at 7:23 AM Graydon graydon@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, Sep 02, 2020 at 10:27:17PM -0000, Martin Honnen
> martin.honnen@xxxxxx 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.
> (It's quite possible I am falsely enamoured of an opportunity for neatness
> and should not try to keep all of this "input element maps to" information
> in the same place.  It still feels like there ought to be way.)
> Is that a bit less like nonsense?
> --
> Graydon Saunders  | graydonish@xxxxxxxxx
> CC&s oferC)ode, C0isses swC! mC&g.
> -- Deor  ("That passed, so may this.")

Dimitre Novatchev
Truly great madness cannot be achieved without significant intelligence.
To invent, you need a good imagination and a pile of junk
Never fight an inanimate object
To avoid situations in which you might make mistakes may be the
biggest mistake of all
Quality means doing it right when no one is looking.
You've achieved success in your field when you don't know whether what
you're doing is work or play
To achieve the impossible dream, try going to sleep.
Facts do not cease to exist because they are ignored.
Typing monkeys will write all Shakespeare's works in 200yrs.Will they write
all patents, too? :)
Sanity is madness put to good use.
I finally figured out the only reason to be alive is to enjoy it.

Current Thread