|
Re: [xsl] recursive sorting by element name -> Xalan Issue
2007-11-29 14:24:24
Hi Scott,
Nevermind entirely -- operator error...thought I was editing the right
file, but it was the wrong file. Got it working now. Thanks for your
help.
Regards,
Davis
On Nov 29, 2007 3:53 PM, Scott Trenda <Scott(_dot_)Trenda(_at_)oati(_dot_)net>
wrote:
+ is just a really short way of converting the not() boolean result to a
number. By "at the bottom", do you mean "under
DictionaryModelDescriptor"? Because it should be putting referentModel
at the top, but since both DictionaryModelDescriptor and referentModel
have @about attributes, the sort is determined by @typeName, then
name().
Did you mean that you need these sorted by the value of the @about
attribute? That's just <xsl:sort select="@about"/>.
~ Scott
-----Original Message-----
From: Davis Ford [mailto:davisford(_at_)gmail(_dot_)com]
Sent: Thursday, November 29, 2007 2:08 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] recursive sorting by element name -> Xalan Issue
This works...kinda, but I get strange behavior (only b/c I don't quite
understand it), when I add two or more instances of nodes that contain
an @about attribute.
For example, if I have an XML file with lots of stuff, and then the
following two entries somewhere randomly placed:
<DictionaryModelDescriptor about="modelName/modelVersion"/>
<referentModel about="blahblah"/>
After the trnasform It puts DictionaryModelDescriptor at the top, and
referentModel at the bottom.
What is + doing here?
On Nov 29, 2007 2:41 PM, Scott Trenda
<Scott(_dot_)Trenda(_at_)oati(_dot_)net> wrote:
No, self:: implies that the context is a node(), and an attribute
doesn't show up on that axis. However, since you're applying templates
to the nodes that will contain the @about attribute, you can omit the
self:: axis altogether. Try this:
<xsl:sort select="+not(@about)"/>
~ Scott
-----Original Message-----
From: Davis Ford [mailto:davisford(_at_)gmail(_dot_)com]
Sent: Thursday, November 29, 2007 1:23 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] recursive sorting by element name -> Xalan Issue
Scott, I just discovered I need a variation on this. Unfortunately,
not all serialized XML uses <DictionaryModelDescriptor>...sometimes it
is called <modelDescriptor>...sometimes...<referentModel>
However, they all do have an @about attribute...so what I really need
to do is sort based on the existence of this attribute.
Would something like this work?
<xsl:sort select="+not(self::@about)"/>
On Nov 29, 2007 2:00 PM, Scott Trenda
<Scott(_dot_)Trenda(_at_)oati(_dot_)net> wrote:
Davis,
Looking at this again, I think I found the shortcut I was hinting at
when I originally posted that sort suggestion. Try this:
<xsl:sort select="+not(self::DictionaryModelDescriptor)"/>
That XPath should do these three things, in order:
1. convert self::DictionaryModelDescriptor to a boolean
2. take the Boolean inverse of the result
3. convert the result to a number.
That will give you 0 for DictionaryModelDescriptor, and 1 for all
other
nodes. The data-type will default to "text" and the order will
default
to "ascending"; that XPath should sort correctly based on those
defaults
in all cases. (I don't know of any collation where 1 precedes 0 in
ascending text-based order.)
It's not as intuitive at-a-glance as I'd hoped, but it's concise and
avoids declarations that could be omitted.
~ Scott
-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com]
Sent: Thursday, November 29, 2007 12:40 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] recursive sorting by element name -> Xalan Issue
The only remaining issue I have appears to be with Xalan.
When I serialize out a collection with JAXB, and apply the
stylesheet (using code posted previously), it sorts
everything and I have no missing attributes, except the
DictionaryModelDescriptor node is now at the bottom of the
file instead of the top. When I run with xsltproc on
mac/linux it places it at the top.
Any idea why I get this behavior?
Yes. boolean(self::x) is true if the node is an x, false otherwise,
Unary
minus converts that to a number and negates the number: so true
becomes
-1,
false becomes 0. You are then sorting that as a string, "-1" versus
"0",
and
the ordering these two strings depends on whether hyphens are
considered
significant by the collating sequence in use. Xalan by default uses
a
collating sequence in which hyphen is considered insignificant.
Change the sort to use data-type="number" and all should be well.
Michael Kay
http://www.saxonica.com/
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:xalan="http://xml.apache.org/xslt"; >
<!-- The xalan param gets back indentation that seems to
be broken in the java api -->
<xsl:output method="xml" indent="yes" encoding="UTF-8"
xalan:indent-amount="4"/>
<xsl:strip-space elements="*" />
<xsl:template match="/">
<xsl:apply-templates />
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:copy-of select="@*"/>
<!-- copy all attributes before
applying templates to children only -->
<xsl:apply-templates select="node()">
<xsl:sort select="-
boolean(self::DictionaryModelDescriptor)"/>
<xsl:sort select="@typeName"/>
<xsl:sort select="name(.)"/>
<xsl:sort />
</xsl:apply-templates>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
On Nov 29, 2007 12:46 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
I am running into some issues / inconsistencies running this
transformation on command line vs. within java vs. which
platform I run
it on. I'm hoping the list might have some pointers on how
to resolve his.
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates
select="@*|node()">
<xsl:sort select="@typeName"/>
<xsl:sort select="name(.)"/>
<xsl:sort />
</xsl:apply-templates>
</xsl:copy>
</xsl:template>
This code may have the effect of sorting child elements before
attributes (specifically a child element with no typeName
attribute
whose name alphabetically precedes the attribute names). You
aren't
allowed to create attributes for an element after creating child
elements. In XSLT 1.0 the processor has the option of ignoring
the
error by discarding the offending attributes.
When I run this on Ubuntu Linux 7.10 (fully updated) using
xsltproc, I
encounter this bug:
https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/147144
Namely, it reports the error:
runtime error: file SortCollections.xsl line 40 element copy
Attribute
nodes must be added before any child nodes to an element.
That doesn't look like a bug to me, it looks like correct
behaviour.
When I run this on Mac OS X 1.5 (Leopard -- fully updated)
using
xsltproc, it does exactly what I want with no problems.
That looks like a bug to me.
When I run this script from Java 1.6 (using JAXB) with the
code below,
the identity transform does not copy all the attributes over.
I end up with missing attributes, and I have no idea why.
Xalan is apparently choosing the option to ignore the error and
discard the attributes.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Zeno Consulting, Inc.
http://www.zenoconsulting.biz
248.894.4922 phone
313.884.2977 fax
--~------------------------------------------------------------------
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Zeno Consulting, Inc.
http://www.zenoconsulting.biz
248.894.4922 phone
313.884.2977 fax
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Zeno Consulting, Inc.
http://www.zenoconsulting.biz
248.894.4922 phone
313.884.2977 fax
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Zeno Consulting, Inc.
http://www.zenoconsulting.biz
248.894.4922 phone
313.884.2977 fax
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
|
|