xsl:element must have a value for name - help

Discussion in 'XML' started by ina, Jun 13, 2006.

  1. ina

    ina Guest

    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 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">
    <xsl:eek:utput 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
     
    ina, Jun 13, 2006
    #1
    1. Advertising

  2. ina

    Joris Gillis Guest

    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 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="1.0">
    <xsl:eek:utput 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)
    «Η αλήθεια και το λάδι πάντα βγαίνουν από πάνω»
     
    Joris Gillis, Jun 13, 2006
    #2
    1. Advertising

  3. ina

    Andy Dingley Guest

    Re: xsl:element must have a value for name - help

    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)
     
    Andy Dingley, Jun 13, 2006
    #3
  4. ina

    ina Guest

    Re: xsl:element must have a value for name - help

    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, Jun 13, 2006
    #4
  5. ina

    Andy Dingley Guest

    Re: xsl:element must have a value for name - help

    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.
     
    Andy Dingley, Jun 13, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MSNews
    Replies:
    1
    Views:
    2,791
    Alvin Bruney [MVP]
    Apr 22, 2004
  2. Y.S.
    Replies:
    3
    Views:
    1,080
    strajan
    Sep 17, 2003
  3. ReignMan
    Replies:
    0
    Views:
    1,168
    ReignMan
    Oct 7, 2003
  4. Replies:
    1
    Views:
    3,687
    A. Bolmarcich
    May 27, 2005
  5. Mike

    XML Element must have CDATA tages around it.

    Mike, Mar 4, 2005, in forum: ASP .Net Web Services
    Replies:
    3
    Views:
    329
    Dan Rogers
    Mar 8, 2005
Loading...

Share This Page