Can xsl throw an exception when value-of xpath does not exist?

Discussion in 'XML' started by inquirydog, Aug 15, 2004.

  1. inquirydog

    inquirydog Guest

    Hi-

    One frusterating thing for me with xsl is that I don't know
    how to make xslt throw some sort of exception when a value-of path
    does not exist. For instance, suppose I have the following line in
    xslt

    <xsl:value-of select="/blah/q" />

    and my xml document does not have a node /blah/q. The output would
    just leave this part of the document empty. Sometimes this is what I
    would like, but often it is indicative of a mistake (for instance, a
    spelling mistake in the node name). Spelling mistakes in the xml
    document can be caught by a schema or dtd, but ones in the xslt
    transformation can not be caught at all (as far as I know). Am I
    incorrect? Is there a way to do this? If not, I would suggest that
    it be added.

    Oh, and I know it *can* be done by using extra coding like
    <xsl:if> but this ceratinly isn't an acceptable solution considering
    that the node has to be typed in twice in the xslt document therefore
    not serving the purpose of testing for spelling mistakes, etc.

    thanks
    -I
    inquirydog, Aug 15, 2004
    #1
    1. Advertising

  2. inquirydog

    Andy Dingley Guest

    On 15 Aug 2004 14:12:36 -0700, (inquirydog)
    wrote:

    > Oh, and I know it *can* be done by using extra coding like
    ><xsl:if> but this ceratinly isn't an acceptable solution


    Stick it in a variable, test the variable, if not empty then output
    the variable.
    Andy Dingley, Aug 16, 2004
    #2
    1. Advertising

  3. (inquirydog) wrote in message news:<>...
    > Hi-
    >
    > One frusterating thing for me with xsl is that I don't know
    > how to make xslt throw some sort of exception when a value-of path
    > does not exist. For instance, suppose I have the following line in
    > xslt
    >
    > <xsl:value-of select="/blah/q" />
    >
    > and my xml document does not have a node /blah/q. The output would
    > just leave this part of the document empty.


    This will do it, since you're using value-of and not copy-of:

    <xsl:variable name="foo">
    <xsl:copy-of select="/blah/q"/>
    </xsl:variable>
    <xsl:choose>
    <xsl:when test="$foo">
    <xsl:value-of select="$foo"/>
    </xsl:when>
    <xsl:eek:therwise>

    <xsl:message><!-- set terminate="yes" for termination -->
    <xsl:text>WARNING: node was unexpectedly empty</xsl:text>
    </xsl:message>

    </xsl:eek:therwise>
    </xsl:choose>

    If /blah/q contained a tree structure you wanted to process further,
    you'd need to use exsl:node-set or XSLT 2.0.
    --
    Robin Johnson
    Lead Developer, enCircle Solutions Ltd.
    first initial last name at encircle dot co dot uk
    Robin Johnson, Aug 16, 2004
    #3
  4. inquirydog

    inquirydog Guest

    Hi-

    Thanks for the response. It is too bad that xslt makes it so
    difficult to do these simple checks. If anyone out there who has some
    say in the future direction of xslt, I would definitely vote to
    somehow add a mode or something that would complain if an xpath
    expression doesn't exist. I am trying to debug someone elses xslt
    right now and it is very difficult to guess the form that they want
    the document in (sure, they could have written a schema to verify
    against, but they didn't. At any rate that would be of little use for
    typos in the stylesheet).

    thanks
    -I


    9.co.uk (Robin Johnson) wrote in message news:<>...
    > (inquirydog) wrote in message news:<>...
    > > Hi-
    > >
    > > One frusterating thing for me with xsl is that I don't know
    > > how to make xslt throw some sort of exception when a value-of path
    > > does not exist. For instance, suppose I have the following line in
    > > xslt
    > >
    > > <xsl:value-of select="/blah/q" />
    > >
    > > and my xml document does not have a node /blah/q. The output would
    > > just leave this part of the document empty.

    >
    > This will do it, since you're using value-of and not copy-of:
    >
    > <xsl:variable name="foo">
    > <xsl:copy-of select="/blah/q"/>
    > </xsl:variable>
    > <xsl:choose>
    > <xsl:when test="$foo">
    > <xsl:value-of select="$foo"/>
    > </xsl:when>
    > <xsl:eek:therwise>
    >
    > <xsl:message><!-- set terminate="yes" for termination -->
    > <xsl:text>WARNING: node was unexpectedly empty</xsl:text>
    > </xsl:message>
    >
    > </xsl:eek:therwise>
    > </xsl:choose>
    >
    > If /blah/q contained a tree structure you wanted to process further,
    > you'd need to use exsl:node-set or XSLT 2.0.
    inquirydog, Aug 17, 2004
    #4

  5. > It is too bad that xslt makes it so
    > difficult to do these simple checks. If anyone out there who has some
    > say in the future direction of xslt, I would definitely vote to
    > somehow add a mode or something that would complain if an xpath
    > expression doesn't exist.




    Why do you find the test

    <xsl:if test="not(/a/b/c)">
    there is no /a/b/c/ element
    </xsl:if>

    hard to use? what syntax would you have in mind that would be more
    direct than this?

    David
    David Carlisle, Aug 17, 2004
    #5
  6. (inquirydog) wrote in message news:<>...
    > Thanks for the response. It is too bad that xslt makes it so
    > difficult to do these simple checks.


    Without meaning to be evangelical, but it looks simple enough to me
    once you get used to the look and feel of XSLT.

    > If anyone out there who has some
    > say in the future direction of xslt


    (Just to make it clear, I have no such say.)

    > I would definitely vote to
    > somehow add a mode or something that would complain if an xpath
    > expression doesn't exist.


    The problem there is, how do you define an XPath expression that
    "doesn't exist?" All XPath expressions 'exist' except syntactically
    invalid ones (which do indeed cause the processor to complain), they
    just sometimes point to empty node-sets. It's easy to test whether a
    node-set expression is empty by slapping an if or a choose round it.

    (True, this sort of thing becomes a fair bit easier when you have a
    proper tree-fragment data type, as in EXSLT or XSLT 2.0.)

    > I am trying to debug someone elses xslt
    > right now and it is very difficult to guess the form that they want
    > the document in (sure, they could have written a schema to verify
    > against, but they didn't.


    Job security, I guess. Can you find any samples of input xml documents
    lying around?

    > At any rate that would be of little use for typos in the stylesheet).


    Well, I don't personally think it's the job of the implementor of a
    programming language to protect you from other people's ambiguous
    typos, but your mileage may vary.
    --
    Robin Johnson
    Lead Developer, enCircle Solutions Ltd.
    first initial last name at encircle dot co dot uk
    Robin Johnson, Aug 17, 2004
    #6
  7. inquirydog

    Andy Dingley Guest

    On 16 Aug 2004 20:13:38 -0700, (inquirydog)
    wrote:

    >It is too bad that xslt makes it so
    >difficult to do these simple checks.


    XSLT syntax is _meant_ to be difficult. It's not for humans to write,
    it's for machines to write. The original "grand plan" involved much
    smarter editors and CASE tools which hid the admitted lumpiness of the
    line-by-line syntax away from the users.


    >I would definitely vote to
    >somehow add a mode or something that would complain if an xpath
    >expression doesn't exist.


    This is really bad and wrong. The values of XPath expressions don't
    "not exist", they evaluate to empty sets. If you think about the
    programming environment in the right way, as a calculus, then this is
    the obvious way to do things. And you _have_ to think about XSLT the
    right way, for if you don't , then it will bite you.

    --
    When the only tool you have is a hammer,
    everything looks like a hard disk.
    Andy Dingley, Aug 17, 2004
    #7
  8. On Tue, 17 Aug 2004 13:49:10 +0100, Andy Dingley
    <> wrote:

    >On 16 Aug 2004 20:13:38 -0700, (inquirydog)
    >wrote:
    >
    >>It is too bad that xslt makes it so
    >>difficult to do these simple checks.

    >
    >XSLT syntax is _meant_ to be difficult. It's not for humans to write,
    >it's for machines to write. The original "grand plan" involved much
    >smarter editors and CASE tools which hid the admitted lumpiness of the
    >line-by-line syntax away from the users.


    Which was, in my opinion, rather misguided; you can't make programming
    easy by sticking on a nice front-end. Programming is hard because
    precise thought is hard, not because you have to remember a lot of
    keywords and syntax.

    Still, the 'lumpiness' of the XML syntax makes it easy to navigate
    your program structure... once you're used to it. My only major gripe
    with the syntax is that comments can't be nested, which can make
    debugging a bit cathedralgic (script-like # comments as a processor
    extension anyone?)
    --
    Robin Johnson
    Lead Developer, enCircle Solutions Ltd.
    first initial last name at encircle dot co dot uk
    Robin Johnson, Aug 17, 2004
    #8
  9. inquirydog

    inquirydog Guest

    >
    > Why do you find the test
    >
    > <xsl:if test="not(/a/b/c)">
    > there is no /a/b/c/ element
    > </xsl:if>



    For starters, it is redundant. There should be a way to do
    the test without having to retype the xpath expression in twice (it
    may be simple to do for your simple /a/b/c example, but less so with
    an xpath expression that is a few hundred characters with interesting
    combinations of operators and functions).

    Also, it puts the burden on the programmer to remember to do
    the test. If you are trying to manage a large group of xslt
    programmers, you have to double check that each is actually making the
    check.

    Third, it doesn't actually stop the processing. In a large
    transformation, the error message would be placed somewhere in the
    output, which might not be noticed for some time.

    Forth, If someone unfamiliar with the project has to make a
    change to the xpath expression, it would be natural for them to search
    and find the expression, change it, and never notice the redundant
    check above. This bug could be not noticed for some time.

    Fifth, it would blow up the size of many transformations quite
    a bit (the test is typically twice the size of the original code).

    Sixth, even if you use a variable to store the condition, you
    have to invent a series of variable names to store the expressions.
    In an xslt transformation with 40 xpath expressions you need 40
    variables. You also need to invent the name of 40 variables.
    Probably you will name them something like xpath1, xpath2, etc. It
    would be easy to accidentally use xpath4 when you meant to use xpath6,
    or something like that. And what do you call a new xpath that gets
    sandwitched between xpath7 and xpath8?


    > hard to use? what syntax would you have in mind that would be more
    > direct than this?



    Could be many things. Perhaps a global processing directive that
    changes the default to expecting that a value-of be non-empty, or to
    exactly contain one item. Perhaps an extra attribute in a value-of to
    expect this (complainIfEmpty="true").

    I am also aware that validation is really in the category of
    schamas, so to be in line with the xml philosophy, perhaps what is
    needed is a way to convert xslt transformations to schemas (this would
    be done by an xslt transformation itself), which could be used to
    prevalidate xml that will be processed by the original xslt
    transformation.

    Or to be completely radical here, why not make the default
    behavior of xslt to expect non empty xpath expressions in value-of?
    Certainly this isn't always what you want, but I would be willing to
    bet that more than often it is what is desired.

    I just want a way to make my envalope addressing xslt look
    like this

    <xsl:value-of select="name" />
    <xsl:value-of select="address" />

    without having to blow this up with ugly redundant checks 90% of the
    time.

    thanks
    -I
    inquirydog, Aug 21, 2004
    #9
  10. inquirydog

    inquirydog Guest

    Greetings-

    > > Thanks for the response. It is too bad that xslt makes it so
    > > difficult to do these simple checks.

    >
    > Without meaning to be evangelical, but it looks simple enough to me
    > once you get used to the look and feel of XSLT.


    I actually am experienced with the whole xslt paradigm. Been
    writting for some time now.


    > > I would definitely vote to
    > > somehow add a mode or something that would complain if an xpath
    > > expression doesn't exist.

    >
    > The problem there is, how do you define an XPath expression that
    > "doesn't exist?" All XPath expressions 'exist' except syntactically
    > invalid ones (which do indeed cause the processor to complain), they
    > just sometimes point to empty node-sets. It's easy to test whether a
    > node-set expression is empty by slapping an if or a choose round it.


    When I used the phrase "doesn't exist" I thought it was clear
    that I meant nodesets of size zero. In some circumstances, any node
    size not equal to one should be considered a problem.

    I am claiming that a check of this type is typically necessary
    to write foolproof scripts.


    > > I am trying to debug someone elses xslt
    > > right now and it is very difficult to guess the form that they want
    > > the document in (sure, they could have written a schema to verify
    > > against, but they didn't.

    >
    > Job security, I guess.


    The script is open source actually.

    > Can you find any samples of input xml documents
    > lying around?


    I looked, and found none. Eventually I had to put in all
    sorts of debug information line by line to find the problems in my
    xml.

    > > At any rate that would be of little use for typos in the stylesheet).

    >
    > Well, I don't personally think it's the job of the implementor of a
    > programming language to protect you from other people's ambiguous
    > typos, but your mileage may vary.


    I couldn't disagree with you more. If a config file is
    missing an important value, the program should comlain and refuse to
    start. If a web service recieves a malformed request, it should
    refuse to process it (think of security alone).

    Right now from what I can see there is no good way to do this
    with xslt.

    thanks
    -I
    inquirydog, Aug 21, 2004
    #10
  11. inquirydog

    inquirydog Guest

    > >It is too bad that xslt makes it so
    > >difficult to do these simple checks.

    >
    > XSLT syntax is _meant_ to be difficult. It's not for humans to write,
    > it's for machines to write. The original "grand plan" involved much
    > smarter editors and CASE tools which hid the admitted lumpiness of the
    > line-by-line syntax away from the users.


    I can accept this, but then I need that grander technology.
    So far I am unaware of a good solution to the problem I mentioned. In
    practice xslt is being written by hand right now. It is a very
    successful technology (arguably the only majorly succesful xml
    technology around today, but that is opening a can of worms), and the
    way it is being used probably won't change for some time. People need
    solutions now, and until xslt can address this problem it will be left
    out of considerations for many projects.

    > >I would definitely vote to
    > >somehow add a mode or something that would complain if an xpath
    > >expression doesn't exist.

    >
    > This is really bad and wrong. The values of XPath expressions don't
    > "not exist", they evaluate to empty sets. If you think about the
    > programming environment in the right way, as a calculus, then this is
    > the obvious way to do things. And you _have_ to think about XSLT the
    > right way, for if you don't , then it will bite you.


    As mentioned in a response above, I thought I was being clear
    when I used the phrase "not exists" I really meant node set size=1,
    but I guess by the double response about this that it wasn't so clear.
    The point is that it is very common to want to check for the unique
    existance of a value-of item. If you would like to address your mail,
    you would use the following transformation

    <xsl:value-of select="name" />
    <xsl:value-of select="address" />

    and if the original xml is missing the name or address, or if they
    appear more than once, you would like to know. Without redundancy or
    much extra work (which will kill a group project) this is impossible
    with xslt as it stands. This will preclude xslt from many projects
    until either modifications are made, or until the appropriate big
    picture technology is written around xslt.

    Looking forward I believe that xslt (or similar technology) it
    the right way to do many things, so it is unfortunate it it is missing
    something so basic right now.

    thanks
    -I
    inquirydog, Aug 21, 2004
    #11
  12. You may prefer XSLT2 (draft, as implemented so far just in saxon8) this
    allows you to specify the expected type of expressions and you'll get a
    type casting error if teh returned expression doesn't have the right
    type (eg it's empty)

    David
    David Carlisle, Aug 21, 2004
    #12
  13. In article <>,
    inquirydog <> wrote:

    % For starters, it is redundant. There should be a way to do
    % the test without having to retype the xpath expression in twice (it

    How about putting the results of the expression in a variable and
    testing that? Sure, the programmer will have to do it, but I guess
    the programmer has to get something right somewhere along the line.
    Surely you don't want your entire process to be dependent on every
    XPath expression returning data.

    You can use xsl:message with terminate='yes' to have the script exit
    immediately.

    Now, you're probably right that there's a deficiency here, but unless
    you come up with a concrete, workable syntax that resolves your specific
    problem, it's difficult to discuss its merits.
    --

    Patrick TJ McPhee
    East York Canada
    Patrick TJ McPhee, Aug 23, 2004
    #13
  14. "inquirydog" <> wrote in message
    news:...

    --snip--

    > The point is that it is very common to want to check for the unique
    > existance of a value-of item. If you would like to address your mail,
    > you would use the following transformation
    >
    > <xsl:value-of select="name" />
    > <xsl:value-of select="address" />
    >
    > and if the original xml is missing the name or address, or if they
    > appear more than once, you would like to know.


    --snip--

    Sorry for getting into this thread so late...

    As far as I can tell, you want to check if an XPath expression evaluates to
    an empty node set, and if so, report this as an error. To me, this is the
    job of a schema (XML Schema, DTD, Relax, ...). If you do not have a schema,
    all bets are off, and you need to check the conditions yourself, in the
    stylesheet or in another way. Personally, if I would need to transform an
    XML document without a schema, I would do some basic checks using Schematron
    (or a custom stylesheet), before transforming.

    What I am trying to say is that I think it is necessary to separate the
    transformation from the "validation".


    // Magnus
    Magnus Henriksson, Aug 23, 2004
    #14
  15. (inquirydog) wrote in message news:<>...
    [wanting to ensure that a node-set is not empty before using it]
    > So far I am unaware of a good solution to the problem I mentioned.


    Honestly, I can't see what's not 'good' about sending the result of
    the expression into a variable and then testing that variable; exactly
    as if you wanted to check that, for example, a numeric expression
    didn't evaluate to zero.

    Can you write a schema for your input documents, and validate them
    against that before running the stylesheet?
    --
    Robin Johnson
    Lead Developer, enCircle Solutions Ltd.
    first initial last name at encircle dot co dot uk
    Robin Johnson, Aug 23, 2004
    #15
  16. inquirydog

    inquirydog Guest

    "Magnus Henriksson" <> wrote in message news:<cgc892$b1k$>...
    >
    > Sorry for getting into this thread so late...
    >
    > As far as I can tell, you want to check if an XPath expression evaluates to
    > an empty node set, and if so, report this as an error. To me, this is the
    > job of a schema (XML Schema, DTD, Relax, ...). If you do not have a schema,
    > all bets are off, and you need to check the conditions yourself, in the
    > stylesheet or in another way. Personally, if I would need to transform an
    > XML document without a schema, I would do some basic checks using Schematron
    > (or a custom stylesheet), before transforming.
    >
    > What I am trying to say is that I think it is necessary to separate the
    > transformation from the "validation".


    I fully agree with this in theory. The problem is that given
    the way that schemas and xsl work today this solution is very flawed.
    Most of the problems that I mentioned above are still not fixed. For
    instance, the xpath expression must be expressed somehow redundantly
    (in the transformation and in the schema). This is a big problem if
    there is a typo in the xslt transformation- ie my schema makes sure
    that I have an element called <dogname>, but the transformation tries
    to use <dawgname>. Oops! Now my results are incorrect and no one is
    there to tell me about it. Second, someone might change the
    transformation and forget to change the schema. Again trouble. Third
    it requires the developer to do much extra work for simple things.

    Modularity in schemas vs transformations would probably be a
    good thing in the final solution to this problem, but as it stands
    today the present solution isn't very useful.

    thanks
    -I
    inquirydog, Aug 27, 2004
    #16
  17. inquirydog

    inquirydog Guest

    (Patrick TJ McPhee) wrote in message news:<>...

    >
    > How about putting the results of the expression in a variable and
    > testing that? Sure, the programmer will have to do it, but I guess
    > the programmer has to get something right somewhere along the line.
    > Surely you don't want your entire process to be dependent on every
    > XPath expression returning data.


    Definitely not! But there needs to be a simple way to test
    for the existence of data for the cases that you need to, which I
    think would be often.

    > You can use xsl:message with terminate='yes' to have the script exit
    > immediately.


    I didn't know about that. That is quite useful to know
    actually (solves part of the problem).

    > Now, you're probably right that there's a deficiency here, but unless
    > you come up with a concrete, workable syntax that resolves your specific
    > problem, it's difficult to discuss its merits.


    I don't know what was not concrete about the solutions I mentioned
    earlier

    > Could be many things. Perhaps a global processing directive that
    > changes the default to expecting that a value-of be non-empty, or to
    > exactly contain one item. Perhaps an extra attribute in a value-of to
    > expect this (complainIfEmpty="true").


    but at any rate I've thought about it some more and have another
    perhaps better solution. What about inventing new elements like
    value-of with type checking in them, like

    <xsl:unique-value-of select="xpath expression"> (checks for
    one and only one node in the node set).

    and other common patterns

    <xsl:value-of-list select=xpath expression" separator=",">
    (prints out a list of nodes separated by the separator, checks that
    the list has at least one element)

    <xsl:apply-unique-template select="xpath expression"> (works
    like xsl:apply-templates, but checks that the node set is of length
    one).

    <xsl:list-apply-template separator="," select="xpath
    expression"> (works like xsl:apply-templates, but checks that the node
    set has one or more elements, and puts the separator between the
    outcomes of the apply templates).

    thanks
    -I
    inquirydog, Aug 27, 2004
    #17
  18. inquirydog

    inquirydog Guest

    9.co.uk (Robin Johnson) wrote in message news:<>...
    > (inquirydog) wrote in message news:<>...
    > [wanting to ensure that a node-set is not empty before using it]
    > > So far I am unaware of a good solution to the problem I mentioned.

    >
    > Honestly, I can't see what's not 'good' about sending the result of
    > the expression into a variable and then testing that variable; exactly
    > as if you wanted to check that, for example, a numeric expression
    > didn't evaluate to zero.


    Sure, I *could* just write the whole thing on a universal
    Turing Machine and get the same results, but why would I want to. In
    many cases to do the value-of properly the work needed to do that will
    be so great that most people will not do it, and as a consequence most
    xslt transformations will not be written to a reasonable enough
    quality that they will be used in the business community.

    I was going to write a simple example of a transformation
    written with just value-of vs full out properly to show you the amount
    the proper way would bulk it out, but decided I don't even want to do
    that. XSLT right now makes certain checks very difficult.

    > Can you write a schema for your input documents, and validate them
    > against that before running the stylesheet?


    See email above.

    thanks
    -I
    inquirydog, Aug 27, 2004
    #18
  19. On 27 Aug 2004 14:40:05 -0700, (inquirydog)
    wrote:
    [...]
    >This is a big problem if
    >there is a typo in the xslt transformation- ie my schema makes sure
    >that I have an element called <dogname>, but the transformation tries
    >to use <dawgname>. Oops! Now my results are incorrect and no one is
    >there to tell me about it.


    Yes, if you type the wrong code, you'll get the wrong results.

    I can't think of a language that doesn't have that 'limitation'.
    --
    Robin Johnson
    Lead Developer, enCircle Solutions Ltd.
    first initial last name at encircle dot co dot uk
    Robin Johnson, Aug 28, 2004
    #19
  20. inquirydog

    inquirydog Guest

    Robin Johnson <9.co.uk> wrote in message news:<>...
    > On 27 Aug 2004 14:40:05 -0700, (inquirydog)
    > wrote:
    > [...]
    > >This is a big problem if
    > >there is a typo in the xslt transformation- ie my schema makes sure
    > >that I have an element called <dogname>, but the transformation tries
    > >to use <dawgname>. Oops! Now my results are incorrect and no one is
    > >there to tell me about it.

    >
    > Yes, if you type the wrong code, you'll get the wrong results.
    >
    > I can't think of a language that doesn't have that 'limitation'.


    Actually, I can't think of a language which doesn't catch typos-

    -----

    c:

    printq("you dude\n");

    compilation result:

    In function `main':
    : undefined reference to `printq'
    collect2: ld returned 1 exit status

    ---

    perl:

    x = x + &;

    run result:

    line 4: syntax error near unexpected token `;'
    line 4: ` x = x + &;'

    ---

    java:

    static public void main(String args[])
    {

    File file = new File("qq");

    file.createNewFile();

    }

    compilation:

    test.java:13: unreported exception java.io.IOException; must be
    caught or
    declared to be thrown
    file.createNewFile();
    ^
    1 error

    (one of the reasons that I love Java is because it is great at compile
    time error checking, finding perhaps 90% of my bugs right off the bat)

    ---

    I am merely requesting that xslt have the same error checking
    capabilities as just about every other language out there (it does in
    some ways, but I am pointing out what I consider to be a large
    ommision in the language). Using a schema to check that address.xml
    has a <street> element in it like this

    <xsd:element name="street" type="xsd:string" />

    and using an xslt transformation with the following typo

    <xsl:value-of select="name" />
    <xsl:value-of select="stret" /> <-- typo, should be street
    <xsl:value-of select="city" /> <xsl:value-of select="state" />
    <xsl:value-of select="zipcode" />

    would contain an error that should be but is not caught by the xslt
    translation software. Granted, as some have pointed out here, you can
    store all xpath expressions in a variable, do a test with instructions
    to complain and stop processing, and then use the value-of with the
    variable, but given that 1). Most people won't do this, and 2). It
    could increase the size of many otherwise simple transformations by
    probably double (ie- consider how big my simple example above would
    become), I don't think this is a reasonable way to do things.


    I believe that xslt is the way of the future of development, and am
    eager to patch all the holes and growing pains that all new
    technologies experience. I've given some of what I believe are
    reasonable suggestions about how I think that should be done, if you
    have a tangible reason why you think they are a bad idea, I would love
    to listen. I am not sure how essentially saying -all languages have
    problems- and throwing up your arms moves xslt forward.

    thanks
    -I
    inquirydog, Aug 29, 2004
    #20
    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. KathyB
    Replies:
    0
    Views:
    754
    KathyB
    Jul 20, 2003
  2. Kerri
    Replies:
    2
    Views:
    12,998
    Kevin Spencer
    Oct 27, 2003
  3. Replies:
    15
    Views:
    7,491
    Roedy Green
    Sep 8, 2005
  4. Pierre Rouleau
    Replies:
    3
    Views:
    6,761
    Siemel Naran
    Mar 4, 2005
  5. Emanuele D'Arrigo

    To throw or to throw not?

    Emanuele D'Arrigo, Nov 14, 2008, in forum: Python
    Replies:
    6
    Views:
    310
    Emanuele D'Arrigo
    Nov 15, 2008
Loading...

Share This Page