Change node:child in attributes

[ina]

Hello all,

I have this xml file:

<FS>
<Style>
<Name>Luca</Name>
<Strategy>
<Strategy_Style>Geo\Asia</Strategy_Style>
<Strategy_Style>Geo\America</Strategy_Style>
<Strategy_Style>Geo\Europe</Strategy_Style>
<Strategy_Style>Sector\America/Cash</Strategy_Style>
</Strategy>
</Style>
<Style>

<Name>George</Name>
<Strategy>
<Strategy_Style>Geo\Asia</Strategy_Style>
<Strategy_Style>Geo\America</Strategy_Style>
<Strategy_Style>Geo\Europe</Strategy_Style>
<Strategy_Style>Sector\America/Cash</Strategy_Style>
</Strategy>
</Style>
</FS>

To have this as output after parsing
<Name>George</Name>
<Strategy>
<Geo Asia = 'yes' America = 'yes' Europe = 'yes'/>
<Sector America/Cash ='yes'/>
</Strategy>

any Suggestions to follow?

Ina

[Joris Gillis]

On Tue, 13 Jun 2006 12:54:04 +0200, ina <ro*************@gmail.com> wrote:

Hello all,

I have this xml file:

<FS>
<Style>
<Name>Luca</Name>
<Strategy>
<Strategy_Style>Geo\Asia</Strategy_Style>
<Strategy_Style>Geo\America</Strategy_Style>
<Strategy_Style>Geo\Europe</Strategy_Style>
<Strategy_Style>Sector\America/Cash</Strategy_Style>
</Strategy>
</Style>
<Style>

<Name>George</Name>
<Strategy>
<Strategy_Style>Geo\Asia</Strategy_Style>
<Strategy_Style>Geo\America</Strategy_Style>
<Strategy_Style>Geo\Europe</Strategy_Style>
<Strategy_Style>Sector\America/Cash</Strategy_Style>
</Strategy>
</Style>
</FS>

To have this as output after parsing

<Name>George</Name>
<Strategy>
<Geo Asia = 'yes' America = 'yes' Europe = 'yes'/>
<Sector America/Cash ='yes'/>
</Strategy>

any Suggestions to follow?

Although I cannot disagree with Andy's analysis, I cannot supress my
desire to tackle any XSLT problem I encounter:-)

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

<xsl:key name="primary" match="Strategy_Style"
use="concat(substring-before(.,'\'),generate-id(..))"/>
<xsl:template match="Strategy">
<xsl:for-each
select="Strategy_Style[generate-id()=generate-id(key('primary',concat(substring-before(.,'\'),generate-id(..)))[1])]">
<xsl:element name="{substring-before(.,'\')}">
<xsl:apply-templates
select="key('primary',concat(substring-before(.,'\'),generate-id(..)))"/>
</xsl:element>
</xsl:for-each>
</xsl:template>

<xsl:template match="Strategy_Style">
<xsl:attribute
name="{translate(substring-after(.,'\'),'/\','_')}">yes</xsl:attribute>
</xsl:template>

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

</xsl:stylesheet>

What this stylesheet does:

By default, alle elements and atributes are copied. This is achieved with
the 'identity transform' template:
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*" />
</xsl:copy>
</xsl:template>

When a 'Strategy' element is encountered, the alorithm creates one element
for each unique pre-slash value in the 'Strategy_Style' children (Uses
muenchian grouping). Once the element is created, it is populated with
attributes by the 'Strategy_Style' template.

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

[Andy Dingley]

ina wrote:

any Suggestions to follow?

Have your XML application re-designed by someone who knows what they're
doing.

By the looks of this, you're trying to build some real business
application _and_ learn the very basics of XML at the same time. That
just isn't a strategy that can end well -- you might even learn some
XML by doing it, but the live application is hardly the right place to
be learning this stuff. If there's a risk that you're making long-term
choices that you're going to have to live with for an appreciable time,
then someone doing their very first steps in XML just isn't the right
person to be architecting things.

To be specific, the XML schema here sucks. Forget about how you process
it, with a million little script fragments and XSLT transforms, you
need to have an underlying schema that works for the business and is
long-term supportable. This one isn't.

Please don't take this the wrong way - as an XML and XSLT student
you're doing great. But I'm concerned that your boss has also thrown
you at this problem and is expecting you to do work you're just not
trained for yet.

[ina]

Thank you for this explanation Andy.

First of all, I am learning xml, yes it is true but you do not know
what i am doing with it you even do not know it is the purpose of that
and of which kind of business are you speak for?

and just ask for any suggestions how to transform xml schema and
another one, that 's all.

Thank you for the answers.

Ina
Andy Dingley <di*****@codesmiths.com> wrote:

ina wrote:

any Suggestions to follow?

Have your XML application re-designed by someone who knows what they're
doing.

By the looks of this, you're trying to build some real business
application _and_ learn the very basics of XML at the same time. That
just isn't a strategy that can end well -- you might even learn some
XML by doing it, but the live application is hardly the right place to
be learning this stuff. If there's a risk that you're making long-term
choices that you're going to have to live with for an appreciable time,
then someone doing their very first steps in XML just isn't the right
person to be architecting things.

To be specific, the XML schema here sucks. Forget about how you process
it, with a million little script fragments and XSLT transforms, you
need to have an underlying schema that works for the business and is
long-term supportable. This one isn't.

Please don't take this the wrong way - as an XML and XSLT student
you're doing great. But I'm concerned that your boss has also thrown
you at this problem and is expecting you to do work you're just not
trained for yet.