Thank you for this explanation. Very helpful.
What I would like to do it is to tag (insert an attribute) with the
style that is corresponding, if it is geographical, sector or whatever
in order to import it to an excel file and be able to do filter from
there.
Ina
Andy Dingley <dingbat@codesmiths.com> wrote:[color=blue]
> ina wrote:
>[color=green]
> > I would like to have this as output
> >
> >
> > <Style>
> > <Strategy>
> > <Asia>Asia</Asia>
> > <America>America</America>
> > <Europe>Europe</Europe>
> > <Style_Strategy>Sector\America\Cash</Style_Strategy>
> > </Strategy>
> > </Style>
> >[/color]
>[color=green]
> > But I have this error: xsl:element must have a value for name
> > attribute? why?[/color]
>
> What could an XML element look like without a name? Obviously it's
> impossible to have such a thing, so of course XSL should raise an error
> in this case.
>
> Secondly, you're generating this name value dynamically and this
> suggests that one of your invocations is trying to use an empty string
> to do it. In particular, substring-after(.,'Geo\') will return an empty
> string if the input string doesn't contain "Geo\" at all (this is a
> nuisance in XSLT and needs many <xsl:choose> statements writing)
>
http://www.w3.org/TR/xpath#function-substring-after
>
> Thirdly I just don't think you should try to do it this way anyway!
>
>
> I've been writing XSLT for a good while now and I can hardly remember
> when I ever used <xsl:element>. This isn't because of anything about
> XSLT, it's because of something about XML.
>
> For very complex reasons (very!) XML needs to have a schema produced
> before the data. You don't have to write this schema down formally, but
> you do need some sort of conceptual view of it. So elements being
> created with random unpredictable names are a bad thing in XML, because
> they make it hard to process them afterwards. The alternative approach
> has been studied in AI work for some years (it's a form of the
> "nominals problem") and is known to be both powerful, but very
> difficult to work with -- it stops many useful automatic techniques
> dead, they just can't process it.
>
> So what does this mean for you? Simply that you should only ever
> generate elements with pre-defined names, not ones with names randomly
> taken from input data. Of course you can _select_ the name to be used,
> based on the input data, but you should still only generate elements
> from a small pre-known set of possibles. Then of course if you know
> what their possible values are, then you can generate them as literal
> result elements in the XSLT, not needing to use <xsl:element>
>
> You have a choice as to whether to write bulky, clear code with literal
> elements in the XSLT, probably selected inside different templates or a
> big <xsl:choose>. Alternatively you can write a line or two of concise
> but unclear code using <xsl:element> and feeding a name parameter
> processed out of the strings. Personally I much prefer the first!
> What you certainly shouldn't do is to blindly generate element names
> that could be anything the input data supplied, and what you simply
> can't do is to use it with unreliable string chopping that might return
> a simply broken ekement name (such as an empty string)[/color]
