Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@XMLXPATH in TCC v33 vs v20

May
609
4
Volume in drive C is Windows-SSD Serial number is 5853:97e1
Directory of C:\Timerefs\windowsZones.xml

05-03-2024 09:35 63,170 windowsZones.xml
63,170 bytes in 1 file and 0 dirs 65,536 bytes allocated
170,205,876,224 bytes free

First and last few lines of windowszones.xml:

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<!--
Copyright ? 1991-2013 Unicode, Inc.
CLDR data files are interpreted according to the LDML specification (http://unicode.org/reports/tr35/)
For terms of use, see http://www.unicode.org/copyright.html
-->

<supplementalData>
        <version number="$Revision$"/>
        <windowsZones>
                <mapTimezones otherVersion="7e11800" typeVersion="2021a">
                        <mapZone other="Samoa Standard Time" territory="001" type="Pacific/Apia"/>
[many lines not shown]
                        <mapZone other="Line Islands Standard Time" territory="ZZ" type="Etc/GMT-14"/>
                </mapTimezones>
        </windowsZones>
</supplementalData>
On TC 20:
Code:
> echo %@xmlxpath["c:\timerefs\windowszones.xml",/supplementalData/windowsZones/mapTimezones/@typeVersion]
2021a

On Tc 33:
Code:
> echo %@xmlxpath["c:\timerefs\windowszones.xml",/supplementalData/windowsZones/mapTimezones/@typeVersion]
TCC:  "/supplementalData/windowsZones/mapTimezones/@typeVersion"

The error message was from STDERR of course.
 
Same result here with v33 - seems to be a bug ...

It's NOT a bug, see my postings below!
 
Last edited:
If testing with the snippet posted is valid, the bug goes back to v27 (and not to v26).
 
Hmm .... I can't discovery a syntax error ... the "typeVersion" is NOT in "mapZone" it's in "mapTimezones" ... can somebody explain it to me?

Ok, have ONE discovered now, the "/@typeVersion" is wrong, should be "[@typeVersion]" probably ...
 
Last edited:
You have at least one syntax error in your @xmlpath statement - either it is missing "mapZone" or the sample you provided is missing a "typeVersion" attribute.
I know next to nothing about XML so I might not be using the right language, but it looks structurally OK to me. typeVersion is a property of mapTimezones (hence the '@'?), not a sub-thingy of it.
 
Ok, seems to me that really the attribut CONTENT is missing of "typeVersion", Rex is right!

Because here is an example WITH attribute:

Code:
<mapTimezones typeVersion="2021a">test2</mapTimezones>

So, the following works:

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<supplementalData>
<windowsZones>
    <mapTimezones typeVersion="2021a">test2</mapTimezones>
</windowsZones>
</supplementalData>

echo %@xmlxpath["D:\_temp\testwinzones.xml",/supplementalData/windowsZones/mapTimezones]
test2

echo %@xmlxpath["D:\_temp\testwinzones.xml",/supplementalData/windowsZones/mapTimezones[@typeVersion]]
test2
 
Last edited:
Don't ask me what it is or where it came from, but here's the file

Code:
"C:\Program Files\Microsoft OneDrive\24.141.0714.0003\tzdata\windowsZones.xml"

with only a few hundred "mapZone" entries (with their associated comments) removed.

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE supplementalData SYSTEM "../../common/dtd/ldmlSupplemental.dtd">
<!--
Copyright © 1991-2013 Unicode, Inc.
CLDR data files are interpreted according to the LDML specification (http://unicode.org/reports/tr35/)
For terms of use, see http://www.unicode.org/copyright.html
-->

<supplementalData>
    <version number="$Revision$"/>
    <windowsZones>
        <mapTimezones otherVersion="7e11800" typeVersion="2021a">

            <!-- (UTC-12:00) International Date Line West -->
            <mapZone other="Dateline Standard Time" territory="001" type="Etc/GMT+12"/>
            <mapZone other="Dateline Standard Time" territory="ZZ" type="Etc/GMT+12"/>

        </mapTimezones>
    </windowsZones>
</supplementalData>
 
The attribute CONTENT is missing here too, see my examples above ...

Also the "/@typeVersion" is wrong, should be "[@typeVersion]" (see my 2nd command line above) ...
 
Something like THIS would work too:

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<supplementalData>
<windowsZones>
    <mapTimezones testattribute="xxxx" typeVersion="2021a">test2</mapTimezones>
</windowsZones>
</supplementalData>

echo %@xmlxpath["D:\_temp\testwinzones.xml",/supplementalData/windowsZones/mapTimezones]
test2

echo %@xmlxpath["D:\_temp\testwinzones.xml",/supplementalData/windowsZones/mapTimezones[@typeVersion]]
test2

But it DOESN'T works without attribute CONTENT ...
 
You have at least one syntax error in your @xmlpath statement - either it is missing "mapZone" or the sample you provided is missing a "typeVersion" attribute.

Note that the XML parser that TCC uses was changed in version 27.
Rex, the typeVersion attribute is in the mapTimezones tag, not in mapZone. I'm trying to get the value of the attribute named typeVersion in the tag mapTimezones. According to the help, I've constructed the query correctly (and it worked correctly in TCC V20). Is this a bug in the XML parser you call?
 
@dcantor

You are right with "it's in mapTimezones" but there is no attribute CONTENT in your example XML with "typeVersion" ... see my postings above (Rex mentioned that too) ... XML parser changed in v27 ... seems no bug to me (and Rex probably too) ...
 
Alpengreis (and Rex),

typeVersion="2021a" is the attribute in mapTimezones. I don't understand why @typeVersion doesn't work.
 
Hello @dcantor

Because "typeVersion" attribute value "2021a" has no content. If it has a content, like the following:

Code:
<mapTimezones testattribute="xxxx" typeVersion="2021a">test2</mapTimezones>

where "test2" is the content, it works.

So "typeVersion" is the attribute name (attrname); "2021a" is the attribute value ("attrvalue") and "test2" is the attribute content.

Without attribut content, the old parser gave "2021a" as output - with the current one, that's no more the case ... there is a content needed.

Greetings

PS: And also your syntax is no more correct for new parser, that means: your ".../mapTimezones/@typeVersion" is not correct, it has to be ".../mapTimezones[@typeVersion]" ...
 
Last edited:
So, if you take the following example:

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<!--
Copyright ? 1991-2013 Unicode, Inc.
CLDR data files are interpreted according to the LDML specification (http://unicode.org/reports/tr35/)
For terms of use, see http://www.unicode.org/copyright.html
-->

<supplementalData>
        <version number="$Revision$"/>
        <windowsZones>
                <mapTimezones otherVersion="7e11800" typeVersion="2021a">test_content
                        <mapZone other="Samoa Standard Time" territory="001" type="Pacific/Apia"/>
                        <mapZone other="Line Islands Standard Time" territory="ZZ" type="Etc/GMT-14"/>
                </mapTimezones>
        </windowsZones>
</supplementalData>

And give the command:

Code:
echo %@xmlxpath["c:\timerefs\windowszones.xml",/supplementalData/windowsZones/mapTimezones[@typeVersion]]
test_content

it works.
 
So, if you take the following example:

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<!--
Copyright ? 1991-2013 Unicode, Inc.
CLDR data files are interpreted according to the LDML specification (http://unicode.org/reports/tr35/)
For terms of use, see http://www.unicode.org/copyright.html
-->

<supplementalData>
        <version number="$Revision$"/>
        <windowsZones>
                <mapTimezones otherVersion="7e11800" typeVersion="2021a">test_content
                        <mapZone other="Samoa Standard Time" territory="001" type="Pacific/Apia"/>
                        <mapZone other="Line Islands Standard Time" territory="ZZ" type="Etc/GMT-14"/>
                </mapTimezones>
        </windowsZones>
</supplementalData>

And give the command:

Code:
echo %@xmlxpath["c:\timerefs\windowszones.xml",/supplementalData/windowsZones/mapTimezones[@typeVersion]]
test_content

it works.

Alpengreis, you are not understanding what I am trying to get. I'm trying get the 2021a which is the value of the typeVersion attribute. The help says to prefix an @ for attributes.
 
I understand you completely. I just pointed out what is possible and what not. IMHO you cannot do that with that (your) XML file with the current parser.
I can't say if all that is WAD - Rex, how is it?
 
Thank you! I thought that, but was not really sure.
 
The old (not really documented, and not technically correct) syntax does not work with the newer XML parser. This is WAD.
Okay, thank you, Rex, for that definitive statement. I suggest therefor, that the line about using @ to prefix to attributes be removed from the help for @XMLXPATH. "To return an attribute, preface the attribute name with an @."

I solved my problem by using a separate program XMLstarlet at XMLStarlet command line XML toolkit .

It accepts the syntax exactly as I was attempting; i.e., the XPATH ends in /@<attribute name>.
Code:
xml sel -T -t -v "/supplementalData/windowsZones/mapTimezones/@typeVersion"
where xml is an alias to the xml.exe program.

Dave C.
 
@dcantor

@ is fully valid! You took the wrong syntax as I said multiple times above (and also Rex said that already) - your "/@" is NEVER correct syntax with @xmlxpath in current parser. But it wouldn't work anyway with your XML ...

But what is when you would have an XLM like the following:

Code:
<?xml version="1.0" encoding="ISO-8859-1"?>
<bookstore>
<book>
    <title lang="eng">Learning XML</title>
    <title lang="ger">Lerne XML</title>
    <price>29.99</price>
</book>
</bookstore>

Now you can take the following syntax:

Code:
echo %@xmlxpath["D:\_temp\testwinzones2.xml",/bookstore/book/title[@lang="eng"]]
Learning XML

echo %@xmlxpath["D:\_temp\testwinzones2.xml",/bookstore/book/title[@lang="ger"]]
Lerne XML

As you can see it's NOT "/@attrname" it's "name[@attrname="attrvalue"]" as described in current help file. AND it does work only if there is a CONTENT (also said that multiple times) like "Learning XML" and "Lerne XML" (which means NOT the "attrvalue").

All that means that the help file is correct with the "@"!
 
Last edited:
Alpengreis, the syntax I'm using DOES work with the program I cited above.

I've got my solution.
Now can we drop this?
 
Yes, I give it up ;-)

PS: Good you found a solution!
 
Last edited:
Back
Top