«

Hello all,

I am newbie in xml and have a problem with this parse.


I have this xml.file


<Style>
<Strategy>
<Style_Strategy>Geo\Asia</Style_Strategy>
<Style_Strategy>Geo\America</Style_Strategy>
<Style_Strategy>Geo\Europe</Universe>
<Style_Strategy>Sector\America\Cash</Style_Strategy>
</Strategy>
</Style>


and


<?xml version='1.0' encoding='utf-8' ?>
<xsl:stylesheet xmlnssl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xslutput method="xml" indent="yes"/>


<xsl:template match="/">
<xsl:for-each select="Style/Strategy/Style_Strategy">
<xsl:variable name="new_tag_name"
select="substring-after(.,'Geo\')"/>
<xsl:element name="{$new_tag_name}">
<xsl:value-of select="$new_tag_name"/>
</xsl:element>
</xsl:for-each>
</xsl:template>


</xsl:stylesheet>


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>


But I have this error: xsl:element must have a value for name
attribute? why?


Ina

On Tue, 13 Jun 2006 09:29:41 +0200, ina <> wrote:

> Hello all,
>
> I am newbie in xml and have a problem with this parse.
>
>
> I have this xml.file
>
>
> <Style>
> <Strategy>
> <Style_Strategy>Geo\Asia</Style_Strategy>
> <Style_Strategy>Geo\America</Style_Strategy>
> <Style_Strategy>Geo\Europe</Universe>
> <Style_Strategy>Sector\America\Cash</Style_Strategy>
> </Strategy>
> </Style>
>
>
> <xsl:template match="/">
> <xsl:for-each select="Style/Strategy/Style_Strategy">
> <xsl:variable name="new_tag_name"
> select="substring-after(.,'Geo\')"/>
> <xsl:element name="{$new_tag_name}">
> <xsl:value-of select="$new_tag_name"/>
> </xsl:element>
> </xsl:for-each>
> </xsl:template>
>
>
> </xsl:stylesheet>

> But I have this error: xsl:element must have a value for name
> attribute? why?

When the element <Style_Strategy>Sector\America\Cash</Style_Strategy> is
processed, $new_tag_name will be empty. Of course it's an error to create
an element without a name... SOmehow, you need to distinguish between the
'Geo' and 'Sector' -situation:

e.g.
<xsl:stylesheet xmlnssl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xslutput method="xml" indent="yes"/>

<xsl:template match="Style_Strategy[starts-with(.,'Geo\')]">
<xsl:variable name="new_tag_name"
select="substring-after(.,'Geo\')"/>
<xsl:element name="{$new_tag_name}">
<xsl:value-of select="$new_tag_name"/>
</xsl:element>
</xsl:template>

<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*" />
</xsl:copy>
</xsl:template>

</xsl:stylesheet>


regards,
--
Joris Gillis (http://users.telenet.be/root-jg/me.html)
«Η αλήθεια και το λάδι πάντα βγαίνουν από πάνω»

ina wrote:

> 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>
>

> But I have this error: xsl:element must have a value for name
> attribute? why?

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)

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 <> wrote:
> ina wrote:
>
> > 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>
> >
>
> > But I have this error: xsl:element must have a value for name
> > attribute? why?
>
> 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)

ina wrote:

> 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.

I wonder if you're trying to do too much with XSLT. XSLT is a
_transform_ tool, to take one document and make other documents from
it. It's not a parser or really a re-formatter. For these quite simple
parse operations you're dealing with here, then you ought to be able to
read them just by parsing. XSLT is useful if you need two different
documents, for different purposes, and having different lifecycles.

If you use XSLT to transform things all over the place, then you have
multiple documents representing basically the same information. This is
obviously a problem to manage them and keep them up-to-date. Simpler to
have one document and just be able to read it from all your different
tools. Try making this more of an XML problem and less of an XSLT
problem.

If you have to use XSLT to transform things regularly, then maybe your
XML schema design isn't as flexible or as easy to use as you might
wish. A single big string of "Geo/America/foo" is really 3 bits of
information, so don't stick them together until you really have to.
You'd probably find it easier to keep this separate in 3 attributes
instead.



PS - you're multi-posting this a lot. I suggest cross-posting each
question just once instead (post to both c.t.x and ms.xml), then we all
get to see the thread afterwards, no matter where each of us is reading
it.