Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #14170 > unrolled thread
| Started by | ofuuzo@gmail.com |
|---|---|
| First post | 2014-08-13 04:02 -0700 |
| Last post | 2014-09-07 23:53 +0200 |
| Articles | 20 — 6 participants |
Back to article view | Back to comp.lang.php
Extracting values from xml file using php/xpath/namespace/simplexml/ ofuuzo@gmail.com - 2014-08-13 04:02 -0700
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-08-13 09:25 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ ofuuzo@gmail.com - 2014-08-14 03:29 -0700
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-08-14 10:06 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-17 19:43 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-08-17 15:21 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-08-17 23:41 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-08-17 18:57 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-09-03 23:10 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-03 20:11 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-09-04 02:42 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-03 21:57 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-09-04 23:21 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-04 20:43 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-09-05 04:08 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Denis McMahon <denismfmcmahon@gmail.com> - 2014-09-05 02:50 +0000
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-05 08:24 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-09-07 11:57 +0200
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ Jerry Stuckle <jstucklex@attglobal.net> - 2014-09-07 09:54 -0400
Re: Extracting values from xml file using php/xpath/namespace/simplexml/ "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-09-07 23:53 +0200
| From | ofuuzo@gmail.com |
|---|---|
| Date | 2014-08-13 04:02 -0700 |
| Subject | Extracting values from xml file using php/xpath/namespace/simplexml/ |
| Message-ID | <a8eb7607-8c39-4062-917c-d815b223a021@googlegroups.com> |
Hi,
I am new in PHP/XML. I can't figure out how to combine xpath/namespace/simplexml/php to extract the values of "dc.title" and "dc.date" in this xml file:
<?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ListRecords>
<record>
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
<oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/">
<dc:title>GAFBone</dc:title>
<dc:date>2014-05-01T00:00:00Z</dc:date>
</oai_dc:dc>
</metadata>
</record>
<record>
......
</record>
....
I need help.
Thank in advance.
-Ofuuzo
[toc] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-08-13 09:25 -0400 |
| Message-ID | <lsfp0k$cpj$1@dont-email.me> |
| In reply to | #14170 |
On 8/13/2014 7:02 AM, ofuuzo@gmail.com wrote: > Hi, > I am new in PHP/XML. I can't figure out how to combine xpath/namespace/simplexml/php to extract the values of "dc.title" and "dc.date" in this xml file: > > <?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> > <ListRecords> > <record> > <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"> > <oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/"> > <dc:title>GAFBone</dc:title> > <dc:date>2014-05-01T00:00:00Z</dc:date> > </oai_dc:dc> > > </metadata> > > </record> > <record> > ...... > </record> > > .... > > I need help. > Thank in advance. > > -Ofuuzo > What have you tried so far? What was the result? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | ofuuzo@gmail.com |
|---|---|
| Date | 2014-08-14 03:29 -0700 |
| Message-ID | <b2d1ddf1-3b88-4f33-9336-d5f77ea186f4@googlegroups.com> |
| In reply to | #14171 |
kl. 15:25:41 UTC+2 onsdag 13. august 2014 skrev Jerry Stuckle følgende:
> On 8/13/2014 7:02 AM, ofuuzo@gmail.com wrote:
>
> > Hi,
>
> > I am new in PHP/XML. I can't figure out how to combine xpath/namespace/simplexml/php to extract the values of "dc.title" and "dc.date" in this xml file:
>
> >
>
> > <?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
> > <ListRecords>
>
> > <record>
>
> > <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
>
> > <oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/">
>
> > <dc:title>GAFBone</dc:title>
>
> > <dc:date>2014-05-01T00:00:00Z</dc:date>
>
> > </oai_dc:dc>
>
> >
>
> > </metadata>
>
> >
>
> > </record>
>
> > <record>
>
> > ......
>
> > </record>
>
> >
>
> > ....
>
> >
>
> > I need help.
>
> > Thank in advance.
>
> >
>
> > -Ofuuzo
>
> >
>
>
>
> What have you tried so far? What was the result?
>
>
>
> --
>
> ==================
>
> Remove the "x" from my email address
>
> Jerry Stuckle
>
> jstucklex@attglobal.net
>
> ==================
I figured it out and it works:
<?php
$dom = new DOMDocument();
$dom->load('http://doaj.org/oai?verb=ListRecords&from=2004-03-01&metadataPrefix=oai_dc&identifier=oai:2305-6754');
$xpath = new DOMXpath($dom);
$xpath->registerNamespace('oai', 'http://www.openarchives.org/OAI/2.0/');
$xpath->registerNamespace('oai-dc', 'http://www.openarchives.org/OAI/2.0/oai_dc/');
$xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
$records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record', NULL, FALSE);
foreach ($records as $entry) {
echo $xpath->evaluate('string(oai:header/oai:identifier)', $entry, FALSE);
echo "\n";
echo $xpath->evaluate('string(oai:header/oai:datestamp)', $entry, FALSE);
echo "\n";
$dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
foreach ($dc as $dcElement){
switch ($dcElement->localName) {
case 'title' :
echo 'Title: '.$dcElement->nodeValue;
echo "\n";
break;
case 'date' :
echo 'Date: '.$dcElement->nodeValue;
echo "\n";
break;
case 'relation' :
echo 'Relation: '.$dcElement->nodeValue;
echo "\n";
break;
}
}
}
?>
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-08-14 10:06 -0400 |
| Message-ID | <lsifpn$e83$1@dont-email.me> |
| In reply to | #14173 |
On 8/14/2014 6:29 AM, ofuuzo@gmail.com wrote:
> kl. 15:25:41 UTC+2 onsdag 13. august 2014 skrev Jerry Stuckle følgende:
>> On 8/13/2014 7:02 AM, ofuuzo@gmail.com wrote:
>>
>>> Hi,
>>
>>> I am new in PHP/XML. I can't figure out how to combine xpath/namespace/simplexml/php to extract the values of "dc.title" and "dc.date" in this xml file:
>>
>>>
>>
>>> <?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd" xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>
>>> <ListRecords>
>>
>>> <record>
>>
>>> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
>>
>>> <oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/">
>>
>>> <dc:title>GAFBone</dc:title>
>>
>>> <dc:date>2014-05-01T00:00:00Z</dc:date>
>>
>>> </oai_dc:dc>
>>
>>>
>>
>>> </metadata>
>>
>>>
>>
>>> </record>
>>
>>> <record>
>>
>>> ......
>>
>>> </record>
>>
>>>
>>
>>> ....
>>
>>>
>>
>>> I need help.
>>
>>> Thank in advance.
>>
>>>
>>
>>> -Ofuuzo
>>
>>>
>>
>>
>>
>> What have you tried so far? What was the result?
>>
>>
>>
>> --
>>
>> ==================
>>
>> Remove the "x" from my email address
>>
>> Jerry Stuckle
>>
>> jstucklex@attglobal.net
>>
>> ==================
>
> I figured it out and it works:
>
> <?php
>
> $dom = new DOMDocument();
> $dom->load('http://doaj.org/oai?verb=ListRecords&from=2004-03-01&metadataPrefix=oai_dc&identifier=oai:2305-6754');
> $xpath = new DOMXpath($dom);
>
> $xpath->registerNamespace('oai', 'http://www.openarchives.org/OAI/2.0/');
> $xpath->registerNamespace('oai-dc', 'http://www.openarchives.org/OAI/2.0/oai_dc/');
> $xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>
> $records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record', NULL, FALSE);
> foreach ($records as $entry) {
> echo $xpath->evaluate('string(oai:header/oai:identifier)', $entry, FALSE);
> echo "\n";
> echo $xpath->evaluate('string(oai:header/oai:datestamp)', $entry, FALSE);
> echo "\n";
>
> $dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
> foreach ($dc as $dcElement){
> switch ($dcElement->localName) {
> case 'title' :
> echo 'Title: '.$dcElement->nodeValue;
> echo "\n";
> break;
> case 'date' :
> echo 'Date: '.$dcElement->nodeValue;
> echo "\n";
> break;
> case 'relation' :
> echo 'Relation: '.$dcElement->nodeValue;
> echo "\n";
> break;
>
> }
> }
> }
> ?>
>
Great!
The DOM functions are a bit more complicated than simpleXML, but I like
them better. And once you get into it, it's not all that hard.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-08-17 19:43 +0200 |
| Message-ID | <1443898.x2o4gcXilq@PointedEars.de> |
| In reply to | #14173 |
ofuuzo@gmail.com wrote:
>> On 8/13/2014 7:02 AM, ofuuzo@gmail.com wrote:
>> > I am new in PHP/XML. I can't figure out how to combine
>> > xpath/namespace/simplexml/php to extract the values of "dc.title" and
>> > "dc.date" in this xml file:
>>
>> > <?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH
>> > xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
>> > http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"
>> > xmlns="http://www.openarchives.org/OAI/2.0/"
>> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>
>> > <ListRecords>
>> > <record>
>> > <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
>> > xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
>> > <oai_dc:dc
>> > xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/">
>> > <dc:title>GAFBone</dc:title>
>> > <dc:date>2014-05-01T00:00:00Z</dc:date>
>> > </oai_dc:dc>
>> > </metadata>
>> > </record>
>> […]
>
> I figured it out and it works:
Given your *stated* requirements, you have written it too complicated,
though.
> <?php
>
> // […]
> $xpath->registerNamespace('oai', 'http://www.openarchives.org/OAI/2.0/');
> $xpath->registerNamespace('oai-dc',
> 'http://www.openarchives.org/OAI/2.0/oai_dc/');
You do not have to register namespaces that you do not use in your XPath
query. See below.
> $xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>
> $records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record',
> NULL, FALSE); foreach ($records as $entry) {
> // […]
> $dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
> foreach ($dc as $dcElement){
> switch ($dcElement->localName) {
> case 'title' :
> echo 'Title: '.$dcElement->nodeValue;
> echo "\n";
> break;
> case 'date' :
> echo 'Date: '.$dcElement->nodeValue;
> echo "\n";
> break;
> case 'relation' :
> echo 'Relation: '.$dcElement->nodeValue;
> echo "\n";
> break;
>
> }
> }
> }
> ?>
You do not have to specify the whole path with XPath if you are certain of
uniqueness (or content with iteration over content-duplicates is
acceptable), and you certainly do not have to iterate over elements to find
matches. All of this is built into XPath, see the XPath 1.0
Specification [0], particularly the “Location Paths” section.
Here it is with SimpleXMLElement, which you can apply to your DOMDocument
approach, too:
<?php
$xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
$xml->registerXPathNamespace('dc', 'http://purl.org/dc/elements/1.1/');
echo $xml->xpath('.//dc:title')[0] . PHP_EOL;
echo $xml->xpath('.//dc:date')[0] . PHP_EOL;
String concatenation (“.”) automatically calls an object’s __toString()
method (here: [1]), so does typecasting the value to string [2].
Note that function array dereferencing (“foo(…)[…]”) was introduced in
PHP 5.4 [3]; if you have not upgraded yet, you should, for better
security [4] and performance [5]. (I have tested this with PHP [CLI]
5.6.0RC3 on GNU/Linux.)
For your next posting to Usenet, please
- read <http://www.catb.org/~esr/faqs/smart-questions.html>;
- post *well-formed* XML, if any: <http://validator.w3.org/>;
- trim your quotations to the relevant minimum, see e.g.
<http://www.netmeister.org/news/learn2quote.html>;
- do not use the borken Google Groups, use a newsreader like KNode or
Thunderbird instead:
* <http://www.kde.org/applications/internet/knode/>
* <http://getthunderbird.com/>;
- get a real name.
_________
[0] <http://www.w3.org/TR/1999/REC-xpath-19991116/>
[1] <http://php.net/manual/en/simplexmlelement.tostring.php>
[2] <http://php.net/manual/en/language.types.type-juggling.php>
[3] <http://php.net/manual/en/migration54.new-features.php>
[4] <http://php.net/archive/2014.php#id2014-08-14-1>
[5] <http://www.lornajane.net/posts/2012/php-5-4-benchmarks>
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-08-17 15:21 -0400 |
| Message-ID | <lsqvb1$rpq$1@dont-email.me> |
| In reply to | #14176 |
On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
> ofuuzo@gmail.com wrote:
>
>>> On 8/13/2014 7:02 AM, ofuuzo@gmail.com wrote:
>>>> I am new in PHP/XML. I can't figure out how to combine
>>>> xpath/namespace/simplexml/php to extract the values of "dc.title" and
>>>> "dc.date" in this xml file:
>>>
>>>> <?xml version="1.0" encoding="UTF-8"?> -<OAI-PMH
>>>> xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/
>>>> http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd"
>>>> xmlns="http://www.openarchives.org/OAI/2.0/"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>>
>>>> <ListRecords>
>>>> <record>
>>>> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
>>>> xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/">
>>>> <oai_dc:dc
>>>> xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/">
>>>> <dc:title>GAFBone</dc:title>
>>>> <dc:date>2014-05-01T00:00:00Z</dc:date>
>>>> </oai_dc:dc>
>>>> </metadata>
>>>> </record>
>>> […]
>>
>> I figured it out and it works:
>
> Given your *stated* requirements, you have written it too complicated,
> though.
>
Not necessarily. And the *stated* requirements may not be *all* of the
requirements.
>> <?php
>>
>> // […]
>> $xpath->registerNamespace('oai', 'http://www.openarchives.org/OAI/2.0/');
>> $xpath->registerNamespace('oai-dc',
>> 'http://www.openarchives.org/OAI/2.0/oai_dc/');
>
> You do not have to register namespaces that you do not use in your XPath
> query. See below.
>
It doesn't hurt - and if he wants to use them in the future, he's
already got it. I often register namespaces I don't need *immediately*.
>> $xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>>
>> $records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record',
>> NULL, FALSE); foreach ($records as $entry) {
>> // […]
>> $dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
>> foreach ($dc as $dcElement){
>> switch ($dcElement->localName) {
>> case 'title' :
>> echo 'Title: '.$dcElement->nodeValue;
>> echo "\n";
>> break;
>> case 'date' :
>> echo 'Date: '.$dcElement->nodeValue;
>> echo "\n";
>> break;
>> case 'relation' :
>> echo 'Relation: '.$dcElement->nodeValue;
>> echo "\n";
>> break;
>>
>> }
>> }
>> }
>> ?>
>
> You do not have to specify the whole path with XPath if you are certain of
> uniqueness (or content with iteration over content-duplicates is
> acceptable), and you certainly do not have to iterate over elements to find
> matches. All of this is built into XPath, see the XPath 1.0
> Specification [0], particularly the “Location Paths” section.
>
Again, it's a good idea to specify the whole path. Unless he created
the XML file, he can't ensure that it will be unique. As for iterating
over the elements - it's not uncommon to do it that way. Otherwise you
have to check to ensure each element exists before using it. By
iterating, you can set default values and change those which exist.
Of course, if you have 100 elements and are only interested in 2-3 of
them, this is way inefficient. However, if you have 5 elements and want
all of them, it can be more efficient and is definitely shorter.
> Here it is with SimpleXMLElement, which you can apply to your DOMDocument
> approach, too:
>
> <?php
> $xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
> $xml->registerXPathNamespace('dc', 'http://purl.org/dc/elements/1.1/');
> echo $xml->xpath('.//dc:title')[0] . PHP_EOL;
> echo $xml->xpath('.//dc:date')[0] . PHP_EOL;
>
Which will give an E_NOTICE if the path does not exist.
> String concatenation (“.”) automatically calls an object’s __toString()
> method (here: [1]), so does typecasting the value to string [2].
>
> Note that function array dereferencing (“foo(…)[…]”) was introduced in
> PHP 5.4 [3]; if you have not upgraded yet, you should, for better
> security [4] and performance [5]. (I have tested this with PHP [CLI]
> 5.6.0RC3 on GNU/Linux.)
>
>
> For your next posting to Usenet, please
>
> - read <http://www.catb.org/~esr/faqs/smart-questions.html>;
>
> - post *well-formed* XML, if any: <http://validator.w3.org/>;
>
> - trim your quotations to the relevant minimum, see e.g.
> <http://www.netmeister.org/news/learn2quote.html>;
>
> - do not use the borken Google Groups, use a newsreader like KNode or
> Thunderbird instead:
>
> * <http://www.kde.org/applications/internet/knode/>
> * <http://getthunderbird.com/>;
>
> - get a real name.
>
> _________
> [0] <http://www.w3.org/TR/1999/REC-xpath-19991116/>
> [1] <http://php.net/manual/en/simplexmlelement.tostring.php>
> [2] <http://php.net/manual/en/language.types.type-juggling.php>
> [3] <http://php.net/manual/en/migration54.new-features.php>
> [4] <http://php.net/archive/2014.php#id2014-08-14-1>
> [5] <http://www.lornajane.net/posts/2012/php-5-4-benchmarks>
>
To the OP:
Better yet - forget "Pointed Head"'s trolling and post just like you did
before. There was nothing wrong with your post.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-08-17 23:41 +0200 |
| Message-ID | <13165688.lB41CWTE6m@PointedEars.de> |
| In reply to | #14177 |
Jerry Stuckle wrote:
> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>> You do not have to register namespaces that you do not use in your XPath
>> query. See below.
>
> It doesn't hurt - and if he wants to use them in the future, he's
> already got it. I often register namespaces I don't need *immediately*.
Premature "optimization"…
>>> $xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>>>
>>> $records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record',
>>> NULL, FALSE); foreach ($records as $entry) {
>>> // […]
>>> $dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
>>> foreach ($dc as $dcElement){
>>> switch ($dcElement->localName) {
>>> case 'title' :
>>> echo 'Title: '.$dcElement->nodeValue;
>>> echo "\n";
>>> break;
>>> case 'date' :
>>> echo 'Date: '.$dcElement->nodeValue;
>>> echo "\n";
>>> break;
>>> case 'relation' :
>>> echo 'Relation: '.$dcElement->nodeValue;
>>> echo "\n";
>>> break;
>>>
>>> }
>>> }
>>> }
>>> ?>
>>
>> You do not have to specify the whole path with XPath if you are certain
>> of uniqueness (or content with iteration over content-duplicates is
>> acceptable), and you certainly do not have to iterate over elements to
>> find
>> matches. All of this is built into XPath, see the XPath 1.0
>> Specification [0], particularly the “Location Paths” section.
>
> Again, it's a good idea to specify the whole path.
No, it is not. It makes the code very inflexible at no advantage. For
example, no elements will be found if the full path is specified and the
namespace prefix or the namespace URI changes. Of course, if the prefix is
not allowed to change you can find out the URI by reading the namespace
attribute, but it would still be an unnecessary step because the pertaining
elements are not of interest here.
> Unless he created the XML file, he can't ensure that it will be unique.
It is not possible to apply XPath to a document whose basic structure is
unknown in any case, so that is a specious argument.
If the target elements are not unique, but exist pair-wise per “record”
element (which can be assumed here), the result will be the same because
SimpleXMLElement::xpath() always returns an array.
However, if that cannot be guaranteed or not only the first match is of
interest, then the best (shortest, most efficient) approach is to first find
the ancestors that are not unique, and then use them as context nodes:
foreach ($xml->xpath('./ListRecords/record') as $record)
{
$title = $record->xpath('.//dc:title')[0];
$date = $record->xpath('.//dc:date')[0];
/* do something with $title and $date */
}
It certainly is _not_ to reinvent the wheel^WXPath query engine like the OP
did.
> As for iterating over the elements - it's not uncommon to do it that way.
It is uncommon to do it the way of the OP among those who know both XPath
and the DOM well.
> Otherwise you have to check to ensure each element exists before using it.
No, one does not have to. That’s the beauty of it.
> By iterating, you can set default values and change those which exist.
One can do that anyway.
> Of course, if you have 100 elements and are only interested in 2-3 of
> them, this is way inefficient. However, if you have 5 elements and want
> all of them, it can be more efficient and is definitely shorter.
The proof is in the pudding. My first suggestion had 4 statements in 5
lines. My new suggestion has 3 statements in 7 lines, not counting the
instantiation and namespace registration. How many had the OP’s? How many
would it have if rewritten to use SimpleXMLElement but keeping the same
approach?
>> Here it is with SimpleXMLElement, which you can apply to your DOMDocument
>> approach, too:
>>
>> <?php
>> $xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
>> $xml->registerXPathNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>> echo $xml->xpath('.//dc:title')[0] . PHP_EOL;
>> echo $xml->xpath('.//dc:date')[0] . PHP_EOL;
>
> Which will give an E_NOTICE if the path does not exist.
You mean it would issue “PHP Notice: Undefined offset: 0”? Yes. But that
would not appear in production because the recommended production setting
includes “& ~E_NOTICE”; whereas E_NOTICE is an error constant, not a message
type.
The result of the array element access would be “null”, where the suggested
defaults could take effect:
$title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
$date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
> To the OP:
>
> Better yet […] post just like you did before. There was nothing wrong
> with your post.
I have stated what was wrong. It is there for all to see. Why do you want
to mislead them? And why do you think name-calling is going to achieve
that?
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-08-17 18:57 -0400 |
| Message-ID | <lsrc1c$enm$1@dont-email.me> |
| In reply to | #14178 |
On 8/17/2014 5:41 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>>> You do not have to register namespaces that you do not use in your XPath
>>> query. See below.
>>
>> It doesn't hurt - and if he wants to use them in the future, he's
>> already got it. I often register namespaces I don't need *immediately*.
>
> Premature "optimization"…
>
No, it is not optimization. It is planning for future enhancements (and
possible reusability). Good design means planning for such - not that
YOU would know.
>>>> $xpath->registerNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>>>>
>>>> $records = $xpath->evaluate('/oai:OAI-PMH/oai:ListRecords/oai:record',
>>>> NULL, FALSE); foreach ($records as $entry) {
>>>> // […]
>>>> $dc = $xpath->evaluate('oai:metadata/oai-dc:dc/dc:*', $entry, FALSE);
>>>> foreach ($dc as $dcElement){
>>>> switch ($dcElement->localName) {
>>>> case 'title' :
>>>> echo 'Title: '.$dcElement->nodeValue;
>>>> echo "\n";
>>>> break;
>>>> case 'date' :
>>>> echo 'Date: '.$dcElement->nodeValue;
>>>> echo "\n";
>>>> break;
>>>> case 'relation' :
>>>> echo 'Relation: '.$dcElement->nodeValue;
>>>> echo "\n";
>>>> break;
>>>>
>>>> }
>>>> }
>>>> }
>>>> ?>
>>>
>>> You do not have to specify the whole path with XPath if you are certain
>>> of uniqueness (or content with iteration over content-duplicates is
>>> acceptable), and you certainly do not have to iterate over elements to
>>> find
>>> matches. All of this is built into XPath, see the XPath 1.0
>>> Specification [0], particularly the “Location Paths” section.
>>
>> Again, it's a good idea to specify the whole path.
>
> No, it is not. It makes the code very inflexible at no advantage. For
> example, no elements will be found if the full path is specified and the
> namespace prefix or the namespace URI changes. Of course, if the prefix is
> not allowed to change you can find out the URI by reading the namespace
> attribute, but it would still be an unnecessary step because the pertaining
> elements are not of interest here.
>
And the wrong path will be found if the elements are not unique. If you
specify the whole path and it is not found, you will get an error. If
you have a non-unique path, you will get very hard to find bugs.
>> Unless he created the XML file, he can't ensure that it will be unique.
>
> It is not possible to apply XPath to a document whose basic structure is
> unknown in any case, so that is a specious argument.
>
He knows the current structure of the document. He does not know the
future structure - which is *exactly why he should specify the whole path*.
> If the target elements are not unique, but exist pair-wise per “record”
> element (which can be assumed here), the result will be the same because
> SimpleXMLElement::xpath() always returns an array.
>
No, the results will only be the same if the values are the same. If
they are not, he could easily pick up incorrect values - and spend hours
trying to debug the problem.
> However, if that cannot be guaranteed or not only the first match is of
> interest, then the best (shortest, most efficient) approach is to first find
> the ancestors that are not unique, and then use them as context nodes:
>
> foreach ($xml->xpath('./ListRecords/record') as $record)
> {
> $title = $record->xpath('.//dc:title')[0];
> $date = $record->xpath('.//dc:date')[0];
>
> /* do something with $title and $date */
> }
>
Only if he knows the path he wants.
> It certainly is _not_ to reinvent the wheel^WXPath query engine like the OP
> did.
>
He did not "reinvent the wheel". He processed the data correctly.
>> As for iterating over the elements - it's not uncommon to do it that way.
>
> It is uncommon to do it the way of the OP among those who know both XPath
> and the DOM well.
>
Only in your mind.
>> Otherwise you have to check to ensure each element exists before using it.
>
> No, one does not have to. That’s the beauty of it.
>
And what do you do when an element doesn't exist? You have to test each
element you're looking at.
>> By iterating, you can set default values and change those which exist.
>
> One can do that anyway.
>
Yes, oh great moron?
>> Of course, if you have 100 elements and are only interested in 2-3 of
>> them, this is way inefficient. However, if you have 5 elements and want
>> all of them, it can be more efficient and is definitely shorter.
>
> The proof is in the pudding. My first suggestion had 4 statements in 5
> lines. My new suggestion has 3 statements in 7 lines, not counting the
> instantiation and namespace registration. How many had the OP’s? How many
> would it have if rewritten to use SimpleXMLElement but keeping the same
> approach?
>
And both of your suggestions will fail in many instances - like with
non-unique elements. The op's will not.
>>> Here it is with SimpleXMLElement, which you can apply to your DOMDocument
>>> approach, too:
>>>
>>> <?php
>>> $xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
>>> $xml->registerXPathNamespace('dc', 'http://purl.org/dc/elements/1.1/');
>>> echo $xml->xpath('.//dc:title')[0] . PHP_EOL;
>>> echo $xml->xpath('.//dc:date')[0] . PHP_EOL;
>>
>> Which will give an E_NOTICE if the path does not exist.
>
> You mean it would issue “PHP Notice: Undefined offset: 0”? Yes. But that
> would not appear in production because the recommended production setting
> includes “& ~E_NOTICE”; whereas E_NOTICE is an error constant, not a message
> type.
>
And the notice is NOT good. It indicates a potential bug in the code.
That's why E_NOTICE is issued. But once again you don't understand good
coding practices. You think that just because a message can be
suppressed it's not a potential problem.
> The result of the array element access would be “null”, where the suggested
> defaults could take effect:
>
> $title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
> $date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
>
And gives the E_NOTICE, which you conveniently ignore.
>> To the OP:
>>
>> Better yet […] post just like you did before. There was nothing wrong
>> with your post.
>
> I have stated what was wrong. It is there for all to see. Why do you want
> to mislead them? And why do you think name-calling is going to achieve
> that?
>
You are a pedantic troll, as you have once again proven (and are known
in multiple newsgroups). And you again proved you know nothing about
good coding practices (as you have also proven in multiple newsgroups).
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-09-03 23:10 +0200 |
| Message-ID | <35250817.Fx3NucNZ4e@PointedEars.de> |
| In reply to | #14179 |
Jerry Stuckle wrote:
> On 8/17/2014 5:41 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>>>> You do not have to register namespaces that you do not use in your
>>>> XPath query. See below.
>>> It doesn't hurt - and if he wants to use them in the future, he's
>>> already got it. I often register namespaces I don't need *immediately*.
>> Premature "optimization"…
>
> No, it is not optimization.
In a way it is.
> It is planning for future enhancements (and possible reusability). Good
> design means planning for such - not that YOU would know.
Trying to take care of all possibilities in advance has never been a logical
approach, nor an economically sound one. There is such a thing as over-
engineering, and this is it.
>>> Again, it's a good idea to specify the whole path.
>>
>> No, it is not. It makes the code very inflexible at no advantage. For
>> example, no elements will be found if the full path is specified and the
>> namespace prefix or the namespace URI changes. Of course, if the prefix
>> is not allowed to change you can find out the URI by reading the
>> namespace attribute, but it would still be an unnecessary step because
>> the pertaining elements are not of interest here.
>
> And the wrong path will be found if the elements are not unique.
No, *if* the elements are not unique, only the first element matching the
path will be found *either way*.
> If you specify the whole path and it is not found, you will get an error.
No, the return value (XPath result) is (an) empty (array) instead, and the
block following the “foreach” statement will not be executed – very silently
even with display_errors set to TRUE/on, error_reporting lit up like a
Christmas tree, and libxml_use_internal_errors(FALSE). That querying non-
existing paths does not lead to errors is the very nature of XPath that
makes it superior to manual tree traversal. Your statements show a
fundamental misconception of that technology.
> If you have a non-unique path, you will get very hard to find bugs.
Which is why I said and recommend that *this* is indeed a possibility that
needs to be taken care of advance, by either always going after the first
result item or using a loop (unless it explicitly does not matter) on the
*XPath result* (where items are already filtered).
>>> Unless he created the XML file, he can't ensure that it will be unique.
>> It is not possible to apply XPath to a document whose basic structure is
>> unknown in any case, so that is a specious argument.
>
> He knows the current structure of the document. He does not know the
> future structure - which is *exactly why he should specify the whole
> path*.
No, because he knows the current structure but not the future one, there is
no point in providing for future changes because the XPath query needs to be
rewritten in any case if the structure changes. Put politely, it is very
optimistic of you to assume that an XML document can only change in ways
that do not affect the namespaces or the existing path in general. In any
case, the provider of the document, if both they and we know what they/we
are doing, would have included a way to distinguish the old from the new
format, such as a version string.
>> If the target elements are not unique, but exist pair-wise per “record”
>> element (which can be assumed here), the result will be the same because
>> SimpleXMLElement::xpath() always returns an array.
>
> No, the results will only be the same if the values are the same.
You want to read more carefully. SimpleXMLElement::xpath() *always* returns
an array (unless the query is *syntactically* in error). It does not matter
how many elements that array has *if* you are always interested in the first
one. There are only two possibilities: a) it is there, then the array has
one or more elements; b) it is not there, then the array has no elements.
>> However, if that cannot be guaranteed or not only the first match is of
>> interest, then the best (shortest, most efficient) approach is to first
>> find the ancestors that are not unique, and then use them as context
>> nodes:
>>
>> foreach ($xml->xpath('./ListRecords/record') as $record)
>> {
>> $title = $record->xpath('.//dc:title')[0];
>> $date = $record->xpath('.//dc:date')[0];
>>
>> /* do something with $title and $date */
>> }
>>
>
> Only if he knows the path he wants.
We can safely assume that he has a fair idea of the path or he would not be
using XPath. The (technical) mistake here is to not use the full potential
of XPath (i.e., to use neither filter conditions nor the context node
mechanism), and to use a comparably inefficient, error-prone filtering loop
instead.
>> It certainly is _not_ to reinvent the wheel^WXPath query engine like the
>> OP did.
>
> He did not "reinvent the wheel". He processed the data correctly.
The processing may have been correct in a way (using nodeValue makes me
doubt that). That is not the issue; but that it was inefficient. There
simply is no need for a *filtering* loop with XPath; filters are *built*
*into* *XPath*.
>>> Otherwise you have to check to ensure each element exists before using
>>> it.
>> No, one does not have to. That’s the beauty of it.
>
> And what do you do when an element doesn't exist? You have to test each
> element you're looking at.
Not with XPath.
>>> By iterating, you can set default values and change those which exist.
>> One can do that anyway.
>
> Yes, oh great moron?
Yes, one can. I had shown it further below, and you had quoted it.
>>> Of course, if you have 100 elements and are only interested in 2-3 of
>>> them, this is way inefficient. However, if you have 5 elements and want
>>> all of them, it can be more efficient and is definitely shorter.
>>
>> The proof is in the pudding. My first suggestion had 4 statements in 5
>> lines. My new suggestion has 3 statements in 7 lines, not counting the
>> instantiation and namespace registration. How many had the OP’s? How
>> many would it have if rewritten to use SimpleXMLElement but keeping the
>> same approach?
>
> And both of your suggestions will fail in many instances - like with
> non-unique elements.
There are circumstances in which the first one gives unexpected results;
I have said so and explained why. The second one does not fail and never
will. Both are more efficient and less error-prone than the OP’s
alternative.
> The op's will not.
There are circumstances in which it will fail. There are others in which it
is error-prone, and even others in which it will simply be inefficient
compared to what a clean XPath solution offers.
>>>> Here it is with SimpleXMLElement, which you can apply to your
>>>> DOMDocument approach, too:
>>>>
>>>> <?php
>>>> $xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
>>>> $xml->registerXPathNamespace('dc',
>>>> 'http://purl.org/dc/elements/1.1/'); echo
>>>> $xml->xpath('.//dc:title')[0] . PHP_EOL; echo
>>>> $xml->xpath('.//dc:date')[0] . PHP_EOL;
>>>
>>> Which will give an E_NOTICE if the path does not exist.
>>
>> You mean it would issue “PHP Notice: Undefined offset: 0”? Yes. But
>> that would not appear in production because the recommended production
>> setting includes “& ~E_NOTICE”; whereas E_NOTICE is an error constant,
>> not a message type.
>
> And the notice is NOT good.
There is no notice then.
> It indicates a potential bug in the code.
Not always.
> That's why E_NOTICE is issued.
Again, E_NOTICE is an error code, not a message type. It is never issued.
Your terminology needs revision.
> But once again you don't understand good coding practices.
My CV says otherwise.
> You think that just because a message can be suppressed it's not a
> potential problem.
It is no problem *here*.
>> The result of the array element access would be “null”, where the
>> suggested defaults could take effect:
>>
>> $title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
>> $date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
>>
>
> And gives the E_NOTICE, which you conveniently ignore.
There will be neither E_NOTICE nor notice because no notices are issued in
the first place.
>>> To the OP:
>>>
>>> Better yet […] post just like you did before. There was nothing wrong
>>> with your post.
>>
>> I have stated what was wrong. It is there for all to see. Why do you
>> want to mislead them? And why do you think name-calling is going to
>> achieve that?
>
> You are a pedantic troll, as you have once again proven (and are known
> in multiple newsgroups). And you again proved you know nothing about
> good coding practices (as you have also proven in multiple newsgroups).
We disagree here; considering our previous exchanges, I am not surprised
about that. However, I think at this point the OP, if they are still
interested, and the dedicated reader in general, will have sufficient
material to help them decide whose advice is more worthwhile: That of a
name-calling may-be IT consultant claiming to be a PHP/software
development/whatnot expert; or that of a factually arguing Zend Certified
PHP Engineer with more than a decade of hands-on professional Web
development experience, including 14 years of professional PHP experience,
under his belt.
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-09-03 20:11 -0400 |
| Message-ID | <lu8ao0$ha6$1@dont-email.me> |
| In reply to | #14206 |
On 9/3/2014 5:10 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 8/17/2014 5:41 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>>>>> You do not have to register namespaces that you do not use in your
>>>>> XPath query. See below.
>>>> It doesn't hurt - and if he wants to use them in the future, he's
>>>> already got it. I often register namespaces I don't need *immediately*.
>>> Premature "optimization"…
>>
>> No, it is not optimization.
>
> In a way it is.
>
No, it is not - which you would know if you understood what premature
optimization is. But we also know you don't.
>> It is planning for future enhancements (and possible reusability). Good
>> design means planning for such - not that YOU would know.
>
> Trying to take care of all possibilities in advance has never been a logical
> approach, nor an economically sound one. There is such a thing as over-
> engineering, and this is it.
>
It is ALWAYS a logical approach to cover reasonable possibilities. It
is also an economically sound one because it means that much less code
you have to rewrite when you have to make changes. But once again you
would rather rewrite a bunch of code instead of doing it right the first
time.
No, this is not over-engineering. It is SMART engineering.
>>>> Again, it's a good idea to specify the whole path.
>>>
>>> No, it is not. It makes the code very inflexible at no advantage. For
>>> example, no elements will be found if the full path is specified and the
>>> namespace prefix or the namespace URI changes. Of course, if the prefix
>>> is not allowed to change you can find out the URI by reading the
>>> namespace attribute, but it would still be an unnecessary step because
>>> the pertaining elements are not of interest here.
>>
>> And the wrong path will be found if the elements are not unique.
>
> No, *if* the elements are not unique, only the first element matching the
> path will be found *either way*.
>
Not if the code is designed correctly - as the OP has done. His code
will catch ALL elements - not just the first.
>> If you specify the whole path and it is not found, you will get an error.
>
> No, the return value (XPath result) is (an) empty (array) instead, and the
> block following the “foreach” statement will not be executed – very silently
> even with display_errors set to TRUE/on, error_reporting lit up like a
> Christmas tree, and libxml_use_internal_errors(FALSE). That querying non-
> existing paths does not lead to errors is the very nature of XPath that
> makes it superior to manual tree traversal. Your statements show a
> fundamental misconception of that technology.
>
It does not lead to PHP syntax errors. But it does lead to errors in
the code. Which again you have proven multiple times you don't understand.
>> If you have a non-unique path, you will get very hard to find bugs.
>
> Which is why I said and recommend that *this* is indeed a possibility that
> needs to be taken care of advance, by either always going after the first
> result item or using a loop (unless it explicitly does not matter) on the
> *XPath result* (where items are already filtered).
>
Exactly. And his code does that. Yours does not.
>>>> Unless he created the XML file, he can't ensure that it will be unique.
>>> It is not possible to apply XPath to a document whose basic structure is
>>> unknown in any case, so that is a specious argument.
>>
>> He knows the current structure of the document. He does not know the
>> future structure - which is *exactly why he should specify the whole
>> path*.
>
> No, because he knows the current structure but not the future one, there is
> no point in providing for future changes because the XPath query needs to be
> rewritten in any case if the structure changes. Put politely, it is very
> optimistic of you to assume that an XML document can only change in ways
> that do not affect the namespaces or the existing path in general. In any
> case, the provider of the document, if both they and we know what they/we
> are doing, would have included a way to distinguish the old from the new
> format, such as a version string.
>
Yes, but with his code he will be able to detect an error, and figure
out what changed in the XML. He will then be able to change his code to
resolve the difference.
In your code he will have no idea there was a change - which can result
in a very difficult to detect (and correct) problem.
>>> If the target elements are not unique, but exist pair-wise per “record”
>>> element (which can be assumed here), the result will be the same because
>>> SimpleXMLElement::xpath() always returns an array.
>>
>> No, the results will only be the same if the values are the same.
>
> You want to read more carefully. SimpleXMLElement::xpath() *always* returns
> an array (unless the query is *syntactically* in error). It does not matter
> how many elements that array has *if* you are always interested in the first
> one. There are only two possibilities: a) it is there, then the array has
> one or more elements; b) it is not there, then the array has no elements.
>
Yes, I KNOW what it returns (better then YOU DO, obviously). But the
element you are interested in may NOT be the first one - there is NEVER
a guarantee that is the case.
You are assuming the first element is always the one the OP wants. That
is generally NOT the case in XML - which is why each element has an
identity as well as a value.
Optional elements may be placed before or after the desired element.
It's also pretty obvious you don't understand XML at all.
>>> However, if that cannot be guaranteed or not only the first match is of
>>> interest, then the best (shortest, most efficient) approach is to first
>>> find the ancestors that are not unique, and then use them as context
>>> nodes:
>>>
>>> foreach ($xml->xpath('./ListRecords/record') as $record)
>>> {
>>> $title = $record->xpath('.//dc:title')[0];
>>> $date = $record->xpath('.//dc:date')[0];
>>>
>>> /* do something with $title and $date */
>>> }
>>>
>>
>> Only if he knows the path he wants.
>
> We can safely assume that he has a fair idea of the path or he would not be
> using XPath. The (technical) mistake here is to not use the full potential
> of XPath (i.e., to use neither filter conditions nor the context node
> mechanism), and to use a comparably inefficient, error-prone filtering loop
> instead.
>
We can assume he has a fair idea of the CURRENT PATH. But now you're
arguing that he use the full path - which is just the opposite of what
you argued before.
Once you have the full path, the loop will pick out the correct values
based on the identity of the element. The loop is neither error-prone
nor is it inefficient. Rather, it is quite efficient unless he has
hundreds of elements), and is not at all prone to any errors - because
he is picking out the elements he wants.
>>> It certainly is _not_ to reinvent the wheel^WXPath query engine like the
>>> OP did.
>>
>> He did not "reinvent the wheel". He processed the data correctly.
>
> The processing may have been correct in a way (using nodeValue makes me
> doubt that). That is not the issue; but that it was inefficient. There
> simply is no need for a *filtering* loop with XPath; filters are *built*
> *into* *XPath*.
>
Once again, unless he has hundreds of elements, it is not inefficient.
But now it is YOU who is prematurely optimizing.
>>>> Otherwise you have to check to ensure each element exists before using
>>>> it.
>>> No, one does not have to. That’s the beauty of it.
>>
>> And what do you do when an element doesn't exist? You have to test each
>> element you're looking at.
>
> Not with XPath.
>
Yes, you do. Correct programming practice (which I know you neither
understand nor observe) requires checking for the existence of a value
before using it.
>>>> By iterating, you can set default values and change those which exist.
>>> One can do that anyway.
>>
>> Yes, oh great moron?
>
> Yes, one can. I had shown it further below, and you had quoted it.
>
I didn't bother to quote your error-prone code, which by your own
admission will produce E_NOTICE messages. And these are always
potential errors in the code logic. Why do you think Zend went to the
trouble of creating these messages?
>>>> Of course, if you have 100 elements and are only interested in 2-3 of
>>>> them, this is way inefficient. However, if you have 5 elements and want
>>>> all of them, it can be more efficient and is definitely shorter.
>>>
>>> The proof is in the pudding. My first suggestion had 4 statements in 5
>>> lines. My new suggestion has 3 statements in 7 lines, not counting the
>>> instantiation and namespace registration. How many had the OP’s? How
>>> many would it have if rewritten to use SimpleXMLElement but keeping the
>>> same approach?
>>
>> And both of your suggestions will fail in many instances - like with
>> non-unique elements.
>
> There are circumstances in which the first one gives unexpected results;
> I have said so and explained why. The second one does not fail and never
> will. Both are more efficient and less error-prone than the OP’s
> alternative.
>
And exactly which circumstances are those? You haven't explained
anything that describes the unexpected results. All you've done is say
your error-prone code is "better".
>> The op's will not.
>
> There are circumstances in which it will fail. There are others in which it
> is error-prone, and even others in which it will simply be inefficient
> compared to what a clean XPath solution offers.
>
It will fail if the XPATH changes. But then that can easily be
detected. Your code will not catch a problem where there are duplicate
elements in different XPATHs, for instance. It is full of holes.
>>>>> Here it is with SimpleXMLElement, which you can apply to your
>>>>> DOMDocument approach, too:
>>>>>
>>>>> <?php
>>>>> $xml = new SimpleXMLElement('tmp/test-oai.xml', 0, true);
>>>>> $xml->registerXPathNamespace('dc',
>>>>> 'http://purl.org/dc/elements/1.1/'); echo
>>>>> $xml->xpath('.//dc:title')[0] . PHP_EOL; echo
>>>>> $xml->xpath('.//dc:date')[0] . PHP_EOL;
>>>>
>>>> Which will give an E_NOTICE if the path does not exist.
>>>
>>> You mean it would issue “PHP Notice: Undefined offset: 0”? Yes. But
>>> that would not appear in production because the recommended production
>>> setting includes “& ~E_NOTICE”; whereas E_NOTICE is an error constant,
>>> not a message type.
>>
>> And the notice is NOT good.
>
> There is no notice then.
>
There isn't when you suppress them. But why do you think E_NOTICE type
errors are generated in PHP (and other languages like C, C++ and Java,
for instance).
>> It indicates a potential bug in the code.
>
> Not always.
>
It ALWAYS indicates a *potential* bug in the code. That's why it is there.
>> That's why E_NOTICE is issued.
>
> Again, E_NOTICE is an error code, not a message type. It is never issued.
> Your terminology needs revision.
>
It is not a SYNTAX error. But it almost always indicates a logical
error in the code.
>> But once again you don't understand good coding practices.
>
> My CV says otherwise.
>
Who gives a damn about what you put in your CV? It's as full of crap as
you are.
>> You think that just because a message can be suppressed it's not a
>> potential problem.
>
> It is no problem *here*.
>
I'm glad I don't have to clean up after any of your code. And I pity
your customers. Do they know how bad you really are?
>>> The result of the array element access would be “null”, where the
>>> suggested defaults could take effect:
>>>
>>> $title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
>>> $date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
>>>
>>
>> And gives the E_NOTICE, which you conveniently ignore.
>
> There will be neither E_NOTICE nor notice because no notices are issued in
> the first place.
>
If you don't suppress E_NOTICE, it will be generated. Suppressing the
message does not mean a potential problem does not exist.
>>>> To the OP:
>>>>
>>>> Better yet […] post just like you did before. There was nothing wrong
>>>> with your post.
>>>
>>> I have stated what was wrong. It is there for all to see. Why do you
>>> want to mislead them? And why do you think name-calling is going to
>>> achieve that?
>>
>> You are a pedantic troll, as you have once again proven (and are known
>> in multiple newsgroups). And you again proved you know nothing about
>> good coding practices (as you have also proven in multiple newsgroups).
>
> We disagree here; considering our previous exchanges, I am not surprised
> about that. However, I think at this point the OP, if they are still
> interested, and the dedicated reader in general, will have sufficient
> material to help them decide whose advice is more worthwhile: That of a
> name-calling may-be IT consultant claiming to be a PHP/software
> development/whatnot expert; or that of a factually arguing Zend Certified
> PHP Engineer with more than a decade of hands-on professional Web
> development experience, including 14 years of professional PHP experience,
> under his belt.
>
>
I'm not surprised, either. You have repeatedly proven you have no idea
of how to implement good coding practices - as you have shown in
multiple newsgroup.
And yes, I think the OP and any other reader will have sufficient
evidence to show just how bad your coding "skills" are. Hopefully some
potential clients of yours will also see this and go somewhere else -
where they will get a GOOD programmer.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-09-04 02:42 +0200 |
| Message-ID | <lu8cgu$s9t$1@solani.org> |
| In reply to | #14207 |
Jerry Stuckle wrote: > On 9/3/2014 5:10 PM, Thomas 'PointedEars' Lahn wrote: >> Jerry Stuckle wrote: >> >>> You are a pedantic troll, as you have once again proven (and are known >>> in multiple newsgroups). And you again proved you know nothing about >>> good coding practices (as you have also proven in multiple newsgroups). >> >> We disagree here; considering our previous exchanges, I am not surprised >> about that. However, I think at this point the OP, if they are still >> interested, and the dedicated reader in general, will have sufficient >> material to help them decide whose advice is more worthwhile: That of a >> name-calling may-be IT consultant claiming to be a PHP/software >> development/whatnot expert; or that of a factually arguing Zend Certified >> PHP Engineer with more than a decade of hands-on professional Web >> development experience, including 14 years of professional PHP experience, >> under his belt. > > I'm not surprised, either. You have repeatedly proven you have no idea > of how to implement good coding practices - as you have shown in > multiple newsgroup. > > And yes, I think the OP and any other reader will have sufficient > evidence to show just how bad your coding "skills" are. Hopefully some > potential clients of yours will also see this and go somewhere else - > where they will get a GOOD programmer. With all due respect, I suggest that both of you avoid argument from authority as well as ad hominem reasoning. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-09-03 21:57 -0400 |
| Message-ID | <lu8gud$jnv$1@dont-email.me> |
| In reply to | #14208 |
On 9/3/2014 8:42 PM, Christoph M. Becker wrote: > Jerry Stuckle wrote: > >> On 9/3/2014 5:10 PM, Thomas 'PointedEars' Lahn wrote: >>> Jerry Stuckle wrote: >>> >>>> You are a pedantic troll, as you have once again proven (and are known >>>> in multiple newsgroups). And you again proved you know nothing about >>>> good coding practices (as you have also proven in multiple newsgroups). >>> >>> We disagree here; considering our previous exchanges, I am not surprised >>> about that. However, I think at this point the OP, if they are still >>> interested, and the dedicated reader in general, will have sufficient >>> material to help them decide whose advice is more worthwhile: That of a >>> name-calling may-be IT consultant claiming to be a PHP/software >>> development/whatnot expert; or that of a factually arguing Zend Certified >>> PHP Engineer with more than a decade of hands-on professional Web >>> development experience, including 14 years of professional PHP experience, >>> under his belt. >> >> I'm not surprised, either. You have repeatedly proven you have no idea >> of how to implement good coding practices - as you have shown in >> multiple newsgroup. >> >> And yes, I think the OP and any other reader will have sufficient >> evidence to show just how bad your coding "skills" are. Hopefully some >> potential clients of yours will also see this and go somewhere else - >> where they will get a GOOD programmer. > > With all due respect, I suggest that both of you avoid argument from > authority as well as ad hominem reasoning. > With all due respect, I respond to trolls as they deserve. And Pointed Head is a well-known troll in several newsgroups. He has quite a reputation - and not a good one, at that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-09-04 23:21 +0200 |
| Message-ID | <2974602.zgg0cvazeg@PointedEars.de> |
| In reply to | #14207 |
Jerry Stuckle wrote:
> On 9/3/2014 5:10 PM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 8/17/2014 5:41 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>>> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>>>>>> You do not have to register namespaces that you do not use in your
>>>>>> XPath query. See below.
>>>>> It doesn't hurt - and if he wants to use them in the future, he's
>>>>> already got it. I often register namespaces I don't need
>>>>> *immediately*.
>>>> Premature "optimization"…
>>> No, it is not optimization.
>> In a way it is.
>
> No, it is not - which you would know if you understood what premature
> optimization is. But we also know you don't.
- Premature optimization is the root of all evil[tm].
- It is not optimization.
- Yes, it is, because …
- No, it's not.
I really don't have time for such a "discussion". I have better things to
do, like being paid for creating robust software and making existing
software more robust.
>>> And the wrong path will be found if the elements are not unique.
>> No, *if* the elements are not unique, only the first element matching the
>> path will be found *either way*.
>
> Not if the code is designed correctly - as the OP has done. His code
> will catch ALL elements - not just the first.
As will making full use of XPath, without a filtering loop.
(You appear to have a serious problem with understanding conditional
statements, and I do not mean PHP.)
>>> If you specify the whole path and it is not found, you will get an
>>> error.
>>
>> No, the return value (XPath result) is (an) empty (array) instead, and
>> the block following the “foreach” statement will not be executed – very
>> silently even with display_errors set to TRUE/on, error_reporting lit up
>> like a Christmas tree, and libxml_use_internal_errors(FALSE). That
>> querying non- existing paths does not lead to errors is the very nature
>> of XPath that makes it superior to manual tree traversal. Your
>
> It does not lead to PHP syntax errors.
You had not claimed there would be a *syntax* error, you have claimed there
would be an error. Assuming that the object of a rebuttal would be what you
have not claimed, is a fallacy.
There is no error in that case; the behavior will be exactly the same
regardless whether you used a full path. Now you are trying to muddy the
issue so that you do not have to admit that you were wrong in the first
place.
> But it does lead to errors in the code.
Using the full *potential* of XPath instead of a filtering loop does not
lead to more errors in the code. Using the full *path* instead of the
context node approach does _not_ lead to less errors, because the XPath
Specification and its implementations simply do not care. If the
syntactically correct XPath does not match a node, for whatever reason,
the result is empty and and query does not result in an error.
>>> If you have a non-unique path, you will get very hard to find bugs.
>>
>> Which is why I said and recommend that *this* is indeed a possibility
>> that needs to be taken care of advance, by either always going after the
>> first result item or using a loop (unless it explicitly does not matter)
>> on the *XPath result* (where items are already filtered).
>
> Exactly. And his code does that.
Yes, to a degree.
> Yours does not.
Plain wrong.
>> No, because he knows the current structure but not the future one, there
>> is no point in providing for future changes because the XPath query needs
>> to be rewritten in any case if the structure changes. Put politely, it
>> is very optimistic of you to assume that an XML document can only change
>> in ways that do not affect the namespaces or the existing path in
>> general. In any case, the provider of the document, if both they and we
>> know what they/we are doing, would have included a way to distinguish the
>> old from the new format, such as a version string.
>
> Yes, but with his code he will be able to detect an error,
> and figure out what changed in the XML. He will then be able to change
> his code to resolve the difference.
No, in general he will not. If the XPath result is empty, execution will
not enter his filtering loop.
> In your code he will have no idea there was a change - which can result
> in a very difficult to detect (and correct) problem.
Without changing their code, they will have no idea that there was a change
in the markup either way. The “foreach” will be a *no-op* either way. The
difference is, though, that with the context node approach there is no need
to iterate over elements that are eventually ignored. This makes the
context node approach more efficient than a filtering loop.
Also, the filtering loop only considers child nodes. Should the markup
change so that the data nodes are no longer child nodes, but other
descendants, the context node approach will still work (BTDT), and the
filtering loop approach will not. This makes the context node approach more
robust than the filtering loop approach.
>>>> If the target elements are not unique, but exist pair-wise per “record”
>>>> element (which can be assumed here), the result will be the same
>>>> because SimpleXMLElement::xpath() always returns an array.
>>> No, the results will only be the same if the values are the same.
>>
>> You want to read more carefully. SimpleXMLElement::xpath() *always*
>> returns an array (unless the query is *syntactically* in error). It does
>> not matter how many elements that array has *if* you are always
>> interested in the first one. There are only two possibilities: a) it is
>> there, then the array has one or more elements; b) it is not there, then
>> the array has no elements.
>
> Yes, I KNOW what it returns (better then YOU DO, obviously).
How come then that you do not see that if the path cannot be matched, with
the *current* code of the OP there is *no way* to detect why?
> But the element you are interested in may NOT be the first one - there is
> NEVER a guarantee that is the case.
I am aware of that. Your problem is not understanding or not wanting to
understand conditional statements in an argument. Hopefully the former.
> You are assuming the first element is always the one the OP wants.
I am not.
> That is generally NOT the case in XML - which is why each element has an
> identity as well as a value.
Nonsense.
> Optional elements may be placed before or after the desired element.
True.
> It's also pretty obvious you don't understand XML at all.
Is that so? Then point out to me the sections in the XML Specification that
back up your claim “every element has an identity as well as a value”.
>>>> However, if that cannot be guaranteed or not only the first match is of
>>>> interest, then the best (shortest, most efficient) approach is to first
>>>> find the ancestors that are not unique, and then use them as context
>>>> nodes:
>>>>
>>>> foreach ($xml->xpath('./ListRecords/record') as $record)
>>>> {
>>>> $title = $record->xpath('.//dc:title')[0];
>>>> $date = $record->xpath('.//dc:date')[0];
>>>>
>>>> /* do something with $title and $date */
>>>> }
(There, you quoted it. Do you *still* want to deny that?)
>>> Only if he knows the path he wants.
>> We can safely assume that he has a fair idea of the path or he would not
>> be using XPath. The (technical) mistake here is to not use the full
>> potential of XPath (i.e., to use neither filter conditions nor the
>> context node mechanism), and to use a comparably inefficient, error-prone
>> filtering loop instead.
>
> We can assume he has a fair idea of the CURRENT PATH. But now you're
> arguing that he use the full path
I am not. I wrote “full potential of XPath”, not “full path”.
Big difference.
> - which is just the opposite of what you argued before.
Wrong.
> Once you have the full path, the loop will pick out the correct values
> based on the identity of the element. [snip nonsense]
XML elements do not have identity. You are confusing this with objects,
presumably.
>>>> It certainly is _not_ to reinvent the wheel^WXPath query engine like
>>>> the OP did.
>>> He did not "reinvent the wheel". He processed the data correctly.
>>
>> The processing may have been correct in a way (using nodeValue makes me
>> doubt that). That is not the issue; but that it was inefficient. There
>> simply is no need for a *filtering* loop with XPath; filters are *built*
>> *into* *XPath*.
>
> Once again, unless he has hundreds of elements, it is not inefficient.
But you do not know that he does not have hundreds of elements. So in
general you cannot make the *sound* claim that it would not be inefficient.
In general it is, compared to making full use of XPath.
> But now it is YOU who is prematurely optimizing.
No. It is a mistake to use XPath but not use its full potential.
>>>>> Otherwise you have to check to ensure each element exists before using
>>>>> it.
>>>> No, one does not have to. That’s the beauty of it.
>>> And what do you do when an element doesn't exist? You have to test each
>>> element you're looking at.
>> Not with XPath.
>
> Yes, you do.
No, if the path cannot be matched, the result is empty. And there is no
error if any prefix subset of the path cannot be matched. For example,
assume the following XML document:
<foo>
<bar>
<baz />
</bar>
</foo>
The result of the XPath query '/foo/bla/baz' is as empty as is that of
'/foo/bar/bla', and neither results in an error, even though there is no
“bla” element as child element of the “foo” element.
IOW, with XPath one does *not* need to test for the existence of the “bla”
element in that context before querying its potential children. This is
different with manual tree traversal, which is therefore more error-prone.
> Correct programming practice (which I know you neither understand nor
> observe) requires checking for the existence of a value before using it.
But we are not talking about a general programming case, we are talking
about XPath, a very specific technology to access very specific (usually
XML-based) information.
Maybe you mean something else with “testing”.
>>>>> By iterating, you can set default values and change those which exist.
>>>> One can do that anyway.
>>> Yes, oh great moron?
>> Yes, one can. I had shown it further below, and you had quoted it.
>
> I didn't bother to quote your error-prone code,
Do you take delight in denial? You did quote my code (at least twice now);
and as for its error-proneness, you are wrong.
> which by your own admission will produce E_NOTICE messages.
I have not admitted anything of the sort. I could not have, because
E_NOTICE still is an error constant, not a message type, to begin with.
> And these are always potential errors in the code logic.
So you claim again. But notices are not “always potential errors in the
code logic”, nor do they signify such.
> Why do you think Zend went to the trouble of creating these messages?
First of all, it was not Zend who created any messages. Second, contrary to
other people, I carefully avoid such intentional fallacies. See also
<https://en.wikipedia.org/wiki/Authorial_intent>.
>> There are circumstances in which the first one gives unexpected results;
>> I have said so and explained why. The second one does not fail and never
>> will. Both are more efficient and less error-prone than the OP’s
>> alternative.
>
> And exactly which circumstances are those? You haven't explained
> anything that describes the unexpected results. All you've done is say
> your error-prone code is "better".
You need to read more carefully.
>>> The op's will not.
>> There are circumstances in which it will fail. There are others in which
>> it is error-prone, and even others in which it will simply be inefficient
>> compared to what a clean XPath solution offers.
>
> It will fail if the XPATH changes. But then that can easily be
> detected.
Only by changing their code.
> Your code will not catch a problem where there are duplicate
> elements in different XPATHs, for instance. It is full of holes.
My code (the second way) was an example on how to use XPath's context node
mechanism to avoid a filtering loop; it was not intended as a complete
solution, nor did I claim that it were. That you do not understand the
context node mechanism and projecting your apparent ill will to everyone
who happens to disagree with you, is not my problem.
That said, the OP’s code needs adjustment as well if it is to handle that
which you call “duplicate elements” (how can there be *duplicates* if
elements have *identity*, as you also claimed?).
>>> [A notice] indicates a potential bug in the code.
>> Not always.
>
> It ALWAYS indicates a *potential* bug in the code. That's why it is
> there.
So you claim again. And again, where is the evidence to back that up?
>>> That's why E_NOTICE is issued.
>> Again, E_NOTICE is an error code, not a message type. It is never
>> issued. Your terminology needs revision.
>
> It is not a SYNTAX error. But it almost always indicates a logical
> error in the code.
Interesting, now it is “*almost* always” already. Will it be “sometimes”
the next time you repeat yourself without evidence to back your statement
up? And when will it have become “possibly”?
>>> But once again you don't understand good coding practices.
>> My CV says otherwise.
>
> Who gives a damn about what you put in your CV?
For example, the people who employ me *because* I am known to write very
clean code (to the extent that several people in the developer community
find the degree of my defensive coding excessive).
Passing the ZCPE exam and getting certified, which I did (as you can also
find in my CV as well as the ZCE Directory), also requires thorough
understanding of that subject. I can only recommend to you that you prepare
for, take and hopefully pass that exam which, as far as I can see, at least
the latter you did not yet.
Preparing for the exam already hones those skills. Zend provides online
exam preparation courses, which, from my own experience, I can very much
recommend taking, too. I would recommend them especially to you because
that way you will get to know PHP developers from all over the world and
lose your destructive “I am always right, everyone else is always wrong”
attitude very quickly, finally.
>>> You think that just because a message can be suppressed it's not a
>>> potential problem.
>> It is no problem *here*.
>
> I'm glad I don't have to clean up after any of your code.
Me too.
> And I pity your customers. Do they know how bad you really are?
I will caution you one last time: Such statements border on, or are, libel.
>>>> The result of the array element access would be “null”, where the
>>>> suggested defaults could take effect:
>>>>
>>>> $title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
>>>> $date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
>>>>
>>> And gives the E_NOTICE, which you conveniently ignore.
>> There will be neither E_NOTICE nor notice because no notices are issued
>> in the first place.
>
> If you don't suppress E_NOTICE, it will be generated. Suppressing the
> message does not mean a potential problem does not exist.
First of all, will you please get your terminology right? You cannot
*suppress* E_NOTICE; it is an *error constant*. You can suppress *(PHP)
notices* by bitwise-OR of an error_reporting value with the negation of that
constant (or its value, but that is error-prone), or the “@” prefix to an
expression.
Second, while it is correct to say that suppressing a message does not mean
a potential problem does not exist, the converse is not true; therefore,
your argument is fallacious.
> Hopefully some potential clients of yours will also see this and go
> somewhere else - where they will get a GOOD programmer.
Someone who fails at simple logic like that, I presume?
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-09-04 20:43 -0400 |
| Message-ID | <lub0uq$8cj$1@dont-email.me> |
| In reply to | #14211 |
On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 9/3/2014 5:10 PM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 8/17/2014 5:41 PM, Thomas 'PointedEars' Lahn wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> On 8/17/2014 1:43 PM, Thomas 'PointedEars' Lahn wrote:
>>>>>>> You do not have to register namespaces that you do not use in your
>>>>>>> XPath query. See below.
>>>>>> It doesn't hurt - and if he wants to use them in the future, he's
>>>>>> already got it. I often register namespaces I don't need
>>>>>> *immediately*.
>>>>> Premature "optimization"…
>>>> No, it is not optimization.
>>> In a way it is.
>>
>> No, it is not - which you would know if you understood what premature
>> optimization is. But we also know you don't.
>
> - Premature optimization is the root of all evil[tm].
> - It is not optimization.
> - Yes, it is, because …
> - No, it's not.
>
> I really don't have time for such a "discussion". I have better things to
> do, like being paid for creating robust software and making existing
> software more robust.
>
No, because you don't have a leg to stand on. You have no idea how to
create "robust software" - that much is VERY CLEAR. I pity the clients
you have fooled.
>>>> And the wrong path will be found if the elements are not unique.
>>> No, *if* the elements are not unique, only the first element matching the
>>> path will be found *either way*.
>>
>> Not if the code is designed correctly - as the OP has done. His code
>> will catch ALL elements - not just the first.
>
> As will making full use of XPath, without a filtering loop.
>
> (You appear to have a serious problem with understanding conditional
> statements, and I do not mean PHP.)
>
You seem to have a serious problem with hiding E_NOTICE messages, then
using variables which haven't been defined. And then you claim there is
no problem...
>>>> If you specify the whole path and it is not found, you will get an
>>>> error.
>>>
>>> No, the return value (XPath result) is (an) empty (array) instead, and
>>> the block following the “foreach” statement will not be executed – very
>>> silently even with display_errors set to TRUE/on, error_reporting lit up
>>> like a Christmas tree, and libxml_use_internal_errors(FALSE). That
>>> querying non- existing paths does not lead to errors is the very nature
>>> of XPath that makes it superior to manual tree traversal. Your
>>
>> It does not lead to PHP syntax errors.
>
> You had not claimed there would be a *syntax* error, you have claimed there
> would be an error. Assuming that the object of a rebuttal would be what you
> have not claimed, is a fallacy.
>
Nope. An error in code is not necessarily a syntax error. Your fallacy
is thinking the only errors are syntax errors. But then you don't
understand there can also be logic errors. Is that why your code is
"robust"?
> There is no error in that case; the behavior will be exactly the same
> regardless whether you used a full path. Now you are trying to muddy the
> issue so that you do not have to admit that you were wrong in the first
> place.
>
Only YOU claim there is no error. The behavior will NOT be the same
whether you used a full path or not. But you're too stoopid to
understand that.
>> But it does lead to errors in the code.
>
> Using the full *potential* of XPath instead of a filtering loop does not
> lead to more errors in the code. Using the full *path* instead of the
> context node approach does _not_ lead to less errors, because the XPath
> Specification and its implementations simply do not care. If the
> syntactically correct XPath does not match a node, for whatever reason,
> the result is empty and and query does not result in an error.
>
NOT using XPath, which is what YOU proposed, can lead to logic errors in
the code. It was *I* who said he should be using the full path. But I
guess you can't even remember what you said.
And just because you have turned off E_NOTICE messages does NOT mean
there is not a potential error. GOOD programmers understand that.
Trolls and hackers don't. And you are both - as is well known in
multiple newsgroups.
>>>> If you have a non-unique path, you will get very hard to find bugs.
>>>
>>> Which is why I said and recommend that *this* is indeed a possibility
>>> that needs to be taken care of advance, by either always going after the
>>> first result item or using a loop (unless it explicitly does not matter)
>>> on the *XPath result* (where items are already filtered).
>>
>> Exactly. And his code does that.
>
> Yes, to a degree.
>
>> Yours does not.
>
> Plain wrong.
>
Plain right. But you're too stoopid to understand that. And you claim
to write "robust code". "Bust code" is more like it.
>>> No, because he knows the current structure but not the future one, there
>>> is no point in providing for future changes because the XPath query needs
>>> to be rewritten in any case if the structure changes. Put politely, it
>>> is very optimistic of you to assume that an XML document can only change
>>> in ways that do not affect the namespaces or the existing path in
>>> general. In any case, the provider of the document, if both they and we
>>> know what they/we are doing, would have included a way to distinguish the
>>> old from the new format, such as a version string.
>>
>> Yes, but with his code he will be able to detect an error,
>> and figure out what changed in the XML. He will then be able to change
>> his code to resolve the difference.
>
> No, in general he will not. If the XPath result is empty, execution will
> not enter his filtering loop.
>
Exactly, and that can easily be detected.
>> In your code he will have no idea there was a change - which can result
>> in a very difficult to detect (and correct) problem.
>
> Without changing their code, they will have no idea that there was a change
> in the markup either way. The “foreach” will be a *no-op* either way. The
> difference is, though, that with the context node approach there is no need
> to iterate over elements that are eventually ignored. This makes the
> context node approach more efficient than a filtering loop.
>
His code will detect the change in the markup. Yours will not, because
you are not using the full XPath. And once again - yours can fail if
the XML happens to have multiple (but different) XPaths with the same
identifiers. The Ops will not.
> Also, the filtering loop only considers child nodes. Should the markup
> change so that the data nodes are no longer child nodes, but other
> descendants, the context node approach will still work (BTDT), and the
> filtering loop approach will not. This makes the context node approach more
> robust than the filtering loop approach.
>
Exactly. That can easily be detected. But it will not silently give
incorrect values if there are multiple XPaths. Your code can.
>>>>> If the target elements are not unique, but exist pair-wise per “record”
>>>>> element (which can be assumed here), the result will be the same
>>>>> because SimpleXMLElement::xpath() always returns an array.
>>>> No, the results will only be the same if the values are the same.
>>>
>>> You want to read more carefully. SimpleXMLElement::xpath() *always*
>>> returns an array (unless the query is *syntactically* in error). It does
>>> not matter how many elements that array has *if* you are always
>>> interested in the first one. There are only two possibilities: a) it is
>>> there, then the array has one or more elements; b) it is not there, then
>>> the array has no elements.
>>
>> Yes, I KNOW what it returns (better then YOU DO, obviously).
>
> How come then that you do not see that if the path cannot be matched, with
> the *current* code of the OP there is *no way* to detect why?
>
It is quite easy - a required variable will not be set (!isset($value)).
But you wouldn't know of this test because you turn off E_NOTICE
messages and just assume everything is OK.
>> But the element you are interested in may NOT be the first one - there is
>> NEVER a guarantee that is the case.
>
> I am aware of that. Your problem is not understanding or not wanting to
> understand conditional statements in an argument. Hopefully the former.
>
I understand them completely. And I understand why your code is busted.
>> You are assuming the first element is always the one the OP wants.
>
> I am not.
>
You sure are. But you obviously have no idea how your code (or XML) works.
>> That is generally NOT the case in XML - which is why each element has an
>> identity as well as a value.
>
> Nonsense.
>
Now I KNOW you don't have any idea how XML works!
>> Optional elements may be placed before or after the desired element.
>
> True.
>
>> It's also pretty obvious you don't understand XML at all.
>
> Is that so? Then point out to me the sections in the XML Specification that
> back up your claim “every element has an identity as well as a value”.
>
Yes, it is so. But I'm not going to bother trying to teach a troll you
claim know so well. It's like trying to teach a pig to sing.
>>>>> However, if that cannot be guaranteed or not only the first match is of
>>>>> interest, then the best (shortest, most efficient) approach is to first
>>>>> find the ancestors that are not unique, and then use them as context
>>>>> nodes:
>>>>>
>>>>> foreach ($xml->xpath('./ListRecords/record') as $record)
>>>>> {
>>>>> $title = $record->xpath('.//dc:title')[0];
>>>>> $date = $record->xpath('.//dc:date')[0];
>>>>>
>>>>> /* do something with $title and $date */
>>>>> }
>
> (There, you quoted it. Do you *still* want to deny that?)
>
Yup, I quoted it - and told you why it it is wrong.
>>>> Only if he knows the path he wants.
>>> We can safely assume that he has a fair idea of the path or he would not
>>> be using XPath. The (technical) mistake here is to not use the full
>>> potential of XPath (i.e., to use neither filter conditions nor the
>>> context node mechanism), and to use a comparably inefficient, error-prone
>>> filtering loop instead.
>>
>> We can assume he has a fair idea of the CURRENT PATH. But now you're
>> arguing that he use the full path
>
> I am not. I wrote “full potential of XPath”, not “full path”.
> Big difference.
>
And exactly what is the difference ACCORDING TO YOUR DEFINITION? There
is no official definition of "full potential of XPath".
Oh, I forgot - trolls are good at making up their own terms, then later
defining them as they see fit, just to try to prove they are not wrong.
It doesn't work, Pointed Head.
>> - which is just the opposite of what you argued before.
>
> Wrong.
>
Yup. Try reading back. Oh, that's right. You read only what you WANT
to believe - not what your WROTE.
>> Once you have the full path, the loop will pick out the correct values
>> based on the identity of the element. [snip nonsense]
>
> XML elements do not have identity. You are confusing this with objects,
> presumably.
>
Nope. Again, you're proving you have no idea how XML works.
>>>>> It certainly is _not_ to reinvent the wheel^WXPath query engine like
>>>>> the OP did.
>>>> He did not "reinvent the wheel". He processed the data correctly.
>>>
>>> The processing may have been correct in a way (using nodeValue makes me
>>> doubt that). That is not the issue; but that it was inefficient. There
>>> simply is no need for a *filtering* loop with XPath; filters are *built*
>>> *into* *XPath*.
>>
>> Once again, unless he has hundreds of elements, it is not inefficient.
>
> But you do not know that he does not have hundreds of elements. So in
> general you cannot make the *sound* claim that it would not be inefficient.
> In general it is, compared to making full use of XPath.
>
Ah, so now you're claiming make "full use of XPath" - despite earlier
this very message you claimed you NEVER SAID THAT.
You can't even remember what you said from one PARAGRAPH to another -
much less one MESSAGE to another.
And yes, I have a pretty good idea he doesn't have hundreds of elements.
I have never seen a single XPath with that many elements, despite using
some quite large XML files. And if there were that many elements, there
would have to be a lot more "case" statements in his loop. The values
are there for a reason - and it is very seldom I have not used virtually
every value for one thing or another in an XML file.
>> But now it is YOU who is prematurely optimizing.
>
> No. It is a mistake to use XPath but not use its full potential.
>
Only to "Pointed Head". The rest of the world knows better.
>>>>>> Otherwise you have to check to ensure each element exists before using
>>>>>> it.
>>>>> No, one does not have to. That’s the beauty of it.
>>>> And what do you do when an element doesn't exist? You have to test each
>>>> element you're looking at.
>>> Not with XPath.
>>
>> Yes, you do.
>
> No, if the path cannot be matched, the result is empty. And there is no
> error if any prefix subset of the path cannot be matched. For example,
> assume the following XML document:
>
> <foo>
> <bar>
> <baz />
> </bar>
> </foo>
>
There is no E_NOTICE if you have E_NOTICE messages disabled. That does
NOT mean there is not an error - only that you have disabled messages.
> The result of the XPath query '/foo/bla/baz' is as empty as is that of
> '/foo/bar/bla', and neither results in an error, even though there is no
> “bla” element as child element of the “foo” element.
>
No, neither results in a syntax or runtime error. But that does NOT
mean an error does not exist in the code - as ANY experienced programmer
understands. Trolls and hackers do not, though.
> IOW, with XPath one does *not* need to test for the existence of the “bla”
> element in that context before querying its potential children. This is
> different with manual tree traversal, which is therefore more error-prone.
>
Good programming practice demands it. But we also know you know nothing
about good programming practices.
>> Correct programming practice (which I know you neither understand nor
>> observe) requires checking for the existence of a value before using it.
>
> But we are not talking about a general programming case, we are talking
> about XPath, a very specific technology to access very specific (usually
> XML-based) information.
>
This is a perfect example of a general programming case. Good
programming practices do not change with the data being used.
> Maybe you mean something else with “testing”.
>
Nope, I meant exactly what I said.
>>>>>> By iterating, you can set default values and change those which exist.
>>>>> One can do that anyway.
>>>> Yes, oh great moron?
>>> Yes, one can. I had shown it further below, and you had quoted it.
>>
>> I didn't bother to quote your error-prone code,
>
> Do you take delight in denial? You did quote my code (at least twice now);
> and as for its error-proneness, you are wrong.
>
I meant I didn't quote it in the immediate message. I also haven't
snipped your crap, because it's a great example of how NOT to product
good code.
>> which by your own admission will produce E_NOTICE messages.
>
> I have not admitted anything of the sort. I could not have, because
> E_NOTICE still is an error constant, not a message type, to begin with.
>
Sure you did. Go back and look.
>> And these are always potential errors in the code logic.
>
> So you claim again. But notices are not “always potential errors in the
> code logic”, nor do they signify such.
>
So much for your "robust code". More like "bust code".
>> Why do you think Zend went to the trouble of creating these messages?
>
> First of all, it was not Zend who created any messages. Second, contrary to
> other people, I carefully avoid such intentional fallacies. See also
> <https://en.wikipedia.org/wiki/Authorial_intent>.
>
ROFLMAO! Once again you prove your stoopidity. Zend created the
interpreter, and the interpreter is what generates the messages. So if
it wasn't Zend, then who was it? Microsoft?
>>> There are circumstances in which the first one gives unexpected results;
>>> I have said so and explained why. The second one does not fail and never
>>> will. Both are more efficient and less error-prone than the OP’s
>>> alternative.
>>
>> And exactly which circumstances are those? You haven't explained
>> anything that describes the unexpected results. All you've done is say
>> your error-prone code is "better".
>
> You need to read more carefully.
>
Nope, I read very carefully. And all you've done is prove you're (once
again) full of $#!t.
>>>> The op's will not.
>>> There are circumstances in which it will fail. There are others in which
>>> it is error-prone, and even others in which it will simply be inefficient
>>> compared to what a clean XPath solution offers.
>>
>> It will fail if the XPATH changes. But then that can easily be
>> detected.
>
> Only by changing their code.
>
You haven't seen the entire code. They can easily detect if XPath
changes, as I indicated above.
>> Your code will not catch a problem where there are duplicate
>> elements in different XPATHs, for instance. It is full of holes.
>
> My code (the second way) was an example on how to use XPath's context node
> mechanism to avoid a filtering loop; it was not intended as a complete
> solution, nor did I claim that it were. That you do not understand the
> context node mechanism and projecting your apparent ill will to everyone
> who happens to disagree with you, is not my problem.
>
And your code generates E_NOTICE messages - which you just ignore by
turning the message off. Hiding a message does NOT mean a problem might
not exist. But this is what I would expect from a troll and a hacker.
> That said, the OP’s code needs adjustment as well if it is to handle that
> which you call “duplicate elements” (how can there be *duplicates* if
> elements have *identity*, as you also claimed?).
>
As I indicated before - different XPaths, but same identity. Once again
you have proven you know nothing about XML.
>>>> [A notice] indicates a potential bug in the code.
>>> Not always.
>>
>> It ALWAYS indicates a *potential* bug in the code. That's why it is
>> there.
>
> So you claim again. And again, where is the evidence to back that up?
>
I don't have a couple of years to teach you good programming practices.
Not that I would bother. It's like trying to teach a pig to sing.
>>>> That's why E_NOTICE is issued.
>>> Again, E_NOTICE is an error code, not a message type. It is never
>>> issued. Your terminology needs revision.
>>
>> It is not a SYNTAX error. But it almost always indicates a logical
>> error in the code.
>
> Interesting, now it is “*almost* always” already. Will it be “sometimes”
> the next time you repeat yourself without evidence to back your statement
> up? And when will it have become “possibly”?
>
Nope, it's "almost always" a logical error. And it's always a
"potential error". The two meanings are parallel. But trolls don't
bother to read the whole message. They just take words out of context -
like you just did.
>>>> But once again you don't understand good coding practices.
>>> My CV says otherwise.
>>
>> Who gives a damn about what you put in your CV?
>
> For example, the people who employ me *because* I am known to write very
> clean code (to the extent that several people in the developer community
> find the degree of my defensive coding excessive).
>
People employ you because they don't know any better. They don't know
how bad and potentially error-prone your code is.
> Passing the ZCPE exam and getting certified, which I did (as you can also
> find in my CV as well as the ZCE Directory), also requires thorough
> understanding of that subject. I can only recommend to you that you prepare
> for, take and hopefully pass that exam which, as far as I can see, at least
> the latter you did not yet.
>
Big deal. All that means is that you can pass an exam. It does not
prove you can do a job. There are millions of "certified" people in
this industry who aren't worth a damn. You're just another one.
> Preparing for the exam already hones those skills. Zend provides online
> exam preparation courses, which, from my own experience, I can very much
> recommend taking, too. I would recommend them especially to you because
> that way you will get to know PHP developers from all over the world and
> lose your destructive “I am always right, everyone else is always wrong”
> attitude very quickly, finally.
>
Preparing for the exam means you can memorize answers. No more, no less.
And no, I'm not always right. But when it comes to you, I am NEVER WRONG.
But you're the one who's always claiming you are right - even when
multiple people in multiple different newsgroups have told you otherwise.
>>>> You think that just because a message can be suppressed it's not a
>>>> potential problem.
>>> It is no problem *here*.
>>
>> I'm glad I don't have to clean up after any of your code.
>
> Me too.
>
>> And I pity your customers. Do they know how bad you really are?
>
> I will caution you one last time: Such statements border on, or are, libel.
>
Be my guest. Sue me. See how far you get.
I'll say it once again. I pity your customers. Do they know how bad
you really are?
If you do sue me, be prepared. I have plenty examples of crap code from
you in this and other newsgroups to prove my case. You'll only hurt
yourself even more.
But then trolls are also full of hot air.
>>>>> The result of the array element access would be “null”, where the
>>>>> suggested defaults could take effect:
>>>>>
>>>>> $title = ($record->xpath('.//dc:title')[0] ?: '(unknown)');
>>>>> $date = ($record->xpath('.//dc:date')[0] ?: '(unknown)');
>>>>>
>>>> And gives the E_NOTICE, which you conveniently ignore.
>>> There will be neither E_NOTICE nor notice because no notices are issued
>>> in the first place.
>>
>> If you don't suppress E_NOTICE, it will be generated. Suppressing the
>> message does not mean a potential problem does not exist.
>
> First of all, will you please get your terminology right? You cannot
> *suppress* E_NOTICE; it is an *error constant*. You can suppress *(PHP)
> notices* by bitwise-OR of an error_reporting value with the negation of that
> constant (or its value, but that is error-prone), or the “@” prefix to an
> expression.
>
E_NOTICE is a message type. You can enable or suppress these messages
with the E_NOTICE constant.
Obviously you don't understand message types, either.
> Second, while it is correct to say that suppressing a message does not mean
> a potential problem does not exist, the converse is not true; therefore,
> your argument is fallacious.
>
I did not argue the converse. So YOUR argument is fallacious.
>> Hopefully some potential clients of yours will also see this and go
>> somewhere else - where they will get a GOOD programmer.
>
> Someone who fails at simple logic like that, I presume?
>
Someone who UNDERSTANDS simple logic like above.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | "Christoph M. Becker" <cmbecker69@arcor.de> |
|---|---|
| Date | 2014-09-05 04:08 +0200 |
| Message-ID | <lub5tu$k7f$3@solani.org> |
| In reply to | #14212 |
Jerry Stuckle wrote: > On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote: >> Jerry Stuckle wrote: > His code will detect the change in the markup. Yours will not, because > you are not using the full XPath. And once again - yours can fail if > the XML happens to have multiple (but different) XPaths with the same > identifiers. The Ops will not. "Mutitple (but different) XPaths"? Do you mean multiple (but different) XPath expressions? >>> That is generally NOT the case in XML - which is why each element has an >>> identity as well as a value. >> >> Nonsense. >> > Now I KNOW you don't have any idea how XML works! You have claimed that "each XML element has a value", what is utter nonsense. >> I am not. I wrote “full potential of XPath”, not “full path”. >> Big difference. > > And exactly what is the difference ACCORDING TO YOUR DEFINITION? There > is no official definition of "full potential of XPath". Ouch! > You haven't seen the entire code. They can easily detect if XPath > changes, as I indicated above. "XPath changes"? > As I indicated before - different XPaths, but same identity. Once again > you have proven you know nothing about XML. "Different XPaths"? > And no, I'm not always right. Exaggeration! > But when it comes to you, I am NEVER WRONG. Fallacy! All in all, I have to admit that your creator is brilliant. I never have met a bot that fooled me so long in thinking it's a human. *plonk* -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2014-09-05 02:50 +0000 |
| Message-ID | <lub8dn$glf$2@dont-email.me> |
| In reply to | #14213 |
On Fri, 05 Sep 2014 04:08:09 +0200, Christoph M. Becker wrote: > Jerry Stuckle wrote: > >> On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote: >>> Jerry Stuckle wrote: > >> His code will detect the change in the markup. Yours will not, because >> you are not using the full XPath. And once again - yours can fail if >> the XML happens to have multiple (but different) XPaths with the same >> identifiers. The Ops will not. > > "Mutitple (but different) XPaths"? Do you mean multiple (but different) > XPath expressions? No Jerry is trying to point out to tpel-troll that if you use a partial xpath instead of a fully qualified xpath to match data in an xml document, there is a risk that if the same partial xpath matches one or more unwanted elements as well as the wanted element(s), the unwanted element (s) will end up as part of the selection. Hence, Jerry is suggesting that it is better from the start to use the fully qualified xpath and namespace, because in Jerry's opinion (whether you agree with it or not) having an obvious error or empty dataset is better than having a dataset that contains incorrect data. You may or may not agree with Jerry on that last point, I happen to think he's got a very valid point - that it's better to know something's gone wrong with the selection process than to end up with an invalid dataset and blithely carry on processing it as if it was valid. As an example, if you were closing out unclaimed bank accounts of deceased people and giving the money to the state, it would be bad to accidentally select some accounts of non-deceased people because someone changed the xml source data and your code didn't handle the change. >>>> That is generally NOT the case in XML - which is why each element has >>>> an identity as well as a value. >>> >>> Nonsense. >>> >> Now I KNOW you don't have any idea how XML works! > > You have claimed that "each XML element has a value", what is utter > nonsense. Be careful that you don't get caught out on the meanings of words as used by other people. In my understanding, every xml element has a value, that value being the content of the element, which may be null. For example, in the document: <? xml version="1.0" encoding="utf-8" standalone="yes" ?> <things> <thing /> <thing> <type>instrument</type> <name>kettle drum</name> </thing> <thing> <type>instrument</type> <name>trombone</name> <owner> <id>x5432</id> </owner> </thing> <thing> <type>vehicle</type> <name>car</name> <owner> <id>x5432</id> </owner> </thing> </things> The value of the first "thing" is null >> You haven't seen the entire code. They can easily detect if XPath >> changes, as I indicated above. > > "XPath changes"? I think Jerry meant if the xml changes. For example, If I change the previous document to add an id element for instruments and a name element for owners, then there might be a problem with xpath that just selected name or id elements without fully qualifying them such that all names would now contain people names as well as instrument names, and all ids would now include instrument ids as well as people ids. A fully qualified selector looking for instrument owner ids would only select ids that were a child of owner that was a child of instrument, rather than any id, just as a fully qualify qualified instrument name selector would only select a name that was a child of an instrument item, rather than selecting any name (including, perhaps, the names of vehicles). eg consider "//name" vs "//instrument//name" vs "/things/thing/instrument/ name" as xpath applied to the above document. Then consider what happens in each case if the upstream generator changes the document and a 'name' child element is added to the 'owner' elements. >> As I indicated before - different XPaths, but same identity. Once >> again you have proven you know nothing about XML. > > "Different XPaths"? Again, I think Jerry is referring to the potential for an upstream change in the xml leading to cases where the xpath, if not fully qualified, might return an incorrect dataset. And I still think his basic premise is right, especially as I often work with xml datasets whose generation is wholly outside of my control. If the upstream changes the dataset, I'd prefer my application to fail gracefully having detected that the dataset has changed rather than soldier blithely on and possibly generate incorrect results as a result of my xpath selectors pulling out an incorrect selection. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-09-05 08:24 -0400 |
| Message-ID | <luca25$o9o$1@dont-email.me> |
| In reply to | #14214 |
On 9/4/2014 10:50 PM, Denis McMahon wrote: > On Fri, 05 Sep 2014 04:08:09 +0200, Christoph M. Becker wrote: > >> Jerry Stuckle wrote: >> >>> On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote: >>>> Jerry Stuckle wrote: >> >>> His code will detect the change in the markup. Yours will not, because >>> you are not using the full XPath. And once again - yours can fail if >>> the XML happens to have multiple (but different) XPaths with the same >>> identifiers. The Ops will not. >> >> "Mutitple (but different) XPaths"? Do you mean multiple (but different) >> XPath expressions? > > No > > Jerry is trying to point out to tpel-troll that if you use a partial xpath > instead of a fully qualified xpath to match data in an xml document, > there is a risk that if the same partial xpath matches one or more > unwanted elements as well as the wanted element(s), the unwanted element > (s) will end up as part of the selection. > > Hence, Jerry is suggesting that it is better from the start to use the > fully qualified xpath and namespace, because in Jerry's opinion (whether > you agree with it or not) having an obvious error or empty dataset is > better than having a dataset that contains incorrect data. > > You may or may not agree with Jerry on that last point, I happen to think > he's got a very valid point - that it's better to know something's gone > wrong with the selection process than to end up with an invalid dataset > and blithely carry on processing it as if it was valid. > > As an example, if you were closing out unclaimed bank accounts of > deceased people and giving the money to the state, it would be bad to > accidentally select some accounts of non-deceased people because someone > changed the xml source data and your code didn't handle the change. > >>>>> That is generally NOT the case in XML - which is why each element has >>>>> an identity as well as a value. >>>> >>>> Nonsense. >>>> >>> Now I KNOW you don't have any idea how XML works! >> >> You have claimed that "each XML element has a value", what is utter >> nonsense. > > Be careful that you don't get caught out on the meanings of words as used > by other people. In my understanding, every xml element has a value, that > value being the content of the element, which may be null. > > For example, in the document: > > <? xml version="1.0" encoding="utf-8" standalone="yes" ?> > <things> > <thing /> > <thing> > <type>instrument</type> > <name>kettle drum</name> > </thing> > <thing> > <type>instrument</type> > <name>trombone</name> > <owner> > <id>x5432</id> > </owner> > </thing> > <thing> > <type>vehicle</type> > <name>car</name> > <owner> > <id>x5432</id> > </owner> > </thing> > </things> > > The value of the first "thing" is null > >>> You haven't seen the entire code. They can easily detect if XPath >>> changes, as I indicated above. >> >> "XPath changes"? > > I think Jerry meant if the xml changes. > > For example, If I change the previous document to add an id element for > instruments and a name element for owners, then there might be a problem > with xpath that just selected name or id elements without fully > qualifying them such that all names would now contain people names as > well as instrument names, and all ids would now include instrument ids as > well as people ids. A fully qualified selector looking for instrument > owner ids would only select ids that were a child of owner that was a > child of instrument, rather than any id, just as a fully qualify > qualified instrument name selector would only select a name that was a > child of an instrument item, rather than selecting any name (including, > perhaps, the names of vehicles). > > eg consider "//name" vs "//instrument//name" vs "/things/thing/instrument/ > name" as xpath applied to the above document. Then consider what happens > in each case if the upstream generator changes the document and a 'name' > child element is added to the 'owner' elements. > >>> As I indicated before - different XPaths, but same identity. Once >>> again you have proven you know nothing about XML. >> >> "Different XPaths"? > > Again, I think Jerry is referring to the potential for an upstream change > in the xml leading to cases where the xpath, if not fully qualified, > might return an incorrect dataset. And I still think his basic premise is > right, especially as I often work with xml datasets whose generation is > wholly outside of my control. If the upstream changes the dataset, I'd > prefer my application to fail gracefully having detected that the dataset > has changed rather than soldier blithely on and possibly generate > incorrect results as a result of my xpath selectors pulling out an > incorrect selection. > Thank you, Denis. You and I have similar approaches on good programming practices. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2014-09-07 11:57 +0200 |
| Message-ID | <1803376.fJyM96K0rL@PointedEars.de> |
| In reply to | #14214 |
Denis McMahon wrote:
> On Fri, 05 Sep 2014 04:08:09 +0200, Christoph M. Becker wrote:
>> Jerry Stuckle wrote:
>>> On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>> His code will detect the change in the markup. Yours will not, because
>>> you are not using the full XPath. And once again - yours can fail if
>>> the XML happens to have multiple (but different) XPaths with the same
>>> identifiers. The Ops will not.
>>
>> "Mutitple (but different) XPaths"? Do you mean multiple (but different)
>> XPath expressions?
>
> No
>
> Jerry is trying to point out to tpel-troll that if you use a partial xpath
> instead of a fully qualified xpath to match data in an xml document,
> there is a risk that if the same partial xpath matches one or more
> unwanted elements as well as the wanted element(s), the unwanted element
> (s) will end up as part of the selection.
If he would have, this would be showing that he does not understand XPath.
As you assume he did, you clearly do not understand XPath.
An XPath query always matches all elements that match that path. In a XML
document
<foo>
<bar id="baz" />
<bar id="bla" />
</foo>
the path '/foo/bar' matches <bar id="baz" /> *and* <bar id="bla" />.
Therefore, the return value of SimpleXMLElement::xpath() is *always* an
array, unless the query is syntactically in error, in which case the return
value is FALSE.
As for “unwanted elements”, it is a fallacy to assume that if the structure
of the XML document changes, a more general query *must* return unwanted
elements. For example, if the structure changes to
<foo>
<bars>
<bar id="baz" />
<bar id="bla" />
</bars>
</foo>
(which makes sense structurally) the result for the more general XPath query
'.//bar' will still contain only wanted elements, namely still only <bar
id="baz" /> and <bar id="bla" />. It could be further refined by using
/bars[1] as *context node* (using '.' in the path), referring only to nodes
*below* that node in the hierarchy of the data structure. This is what I
referred to with flexibility.
IOW: Using the full XPath path is _not_ always the best approach.
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2014-09-07 09:54 -0400 |
| Message-ID | <luho38$ni7$1@dont-email.me> |
| In reply to | #14217 |
On 9/7/2014 5:57 AM, Thomas 'PointedEars' Lahn wrote: > Denis McMahon wrote: > >> On Fri, 05 Sep 2014 04:08:09 +0200, Christoph M. Becker wrote: >>> Jerry Stuckle wrote: >>>> On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote: >>>>> Jerry Stuckle wrote: >>>> His code will detect the change in the markup. Yours will not, because >>>> you are not using the full XPath. And once again - yours can fail if >>>> the XML happens to have multiple (but different) XPaths with the same >>>> identifiers. The Ops will not. >>> >>> "Mutitple (but different) XPaths"? Do you mean multiple (but different) >>> XPath expressions? >> >> No >> >> Jerry is trying to point out to tpel-troll that if you use a partial xpath >> instead of a fully qualified xpath to match data in an xml document, >> there is a risk that if the same partial xpath matches one or more >> unwanted elements as well as the wanted element(s), the unwanted element >> (s) will end up as part of the selection. > > If he would have, this would be showing that he does not understand XPath. > As you assume he did, you clearly do not understand XPath. > > An XPath query always matches all elements that match that path. In a XML > document > > <foo> > <bar id="baz" /> > <bar id="bla" /> > </foo> > > the path '/foo/bar' matches <bar id="baz" /> *and* <bar id="bla" />. > > Therefore, the return value of SimpleXMLElement::xpath() is *always* an > array, unless the query is syntactically in error, in which case the return > value is FALSE. > > As for “unwanted elements”, it is a fallacy to assume that if the structure > of the XML document changes, a more general query *must* return unwanted > elements. For example, if the structure changes to > > <foo> > <bars> > <bar id="baz" /> > <bar id="bla" /> > </bars> > </foo> > > (which makes sense structurally) the result for the more general XPath query > './/bar' will still contain only wanted elements, namely still only <bar > id="baz" /> and <bar id="bla" />. It could be further refined by using > /bars[1] as *context node* (using '.' in the path), referring only to nodes > *below* that node in the hierarchy of the data structure. This is what I > referred to with flexibility. > > IOW: Using the full XPath path is _not_ always the best approach. > Once again you're as full of crap as your code is full of holes. But I should know better than to try to teach the troll. It's like trying to teach a pig to sing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2014-09-07 23:53 +0200 |
| Message-ID | <c742dvFfn9lU1@mid.uni-berlin.de> |
| In reply to | #14218 |
Am 07.09.2014 15:54, schrieb Jerry Stuckle: > On 9/7/2014 5:57 AM, Thomas 'PointedEars' Lahn wrote: >> Denis McMahon wrote: >> >>> On Fri, 05 Sep 2014 04:08:09 +0200, Christoph M. Becker wrote: >>>> Jerry Stuckle wrote: >>>>> On 9/4/2014 5:21 PM, Thomas 'Pointed Head' Lahn wrote: >>>>>> Jerry Stuckle wrote: >>>>> His code will detect the change in the markup. Yours will not, because >>>>> you are not using the full XPath. And once again - yours can fail if >>>>> the XML happens to have multiple (but different) XPaths with the same >>>>> identifiers. The Ops will not. >>>> >>>> "Mutitple (but different) XPaths"? Do you mean multiple (but different) >>>> XPath expressions? >>> >>> No >>> >>> Jerry is trying to point out to tpel-troll that if you use a partial xpath >>> instead of a fully qualified xpath to match data in an xml document, >>> there is a risk that if the same partial xpath matches one or more >>> unwanted elements as well as the wanted element(s), the unwanted element >>> (s) will end up as part of the selection. >> >> If he would have, this would be showing that he does not understand XPath. >> As you assume he did, you clearly do not understand XPath. >> >> An XPath query always matches all elements that match that path. In a XML >> document >> >> <foo> >> <bar id="baz" /> >> <bar id="bla" /> >> </foo> >> >> the path '/foo/bar' matches <bar id="baz" /> *and* <bar id="bla" />. >> >> Therefore, the return value of SimpleXMLElement::xpath() is *always* an >> array, unless the query is syntactically in error, in which case the return >> value is FALSE. >> >> As for “unwanted elements”, it is a fallacy to assume that if the structure >> of the XML document changes, a more general query *must* return unwanted >> elements. For example, if the structure changes to >> >> <foo> >> <bars> >> <bar id="baz" /> >> <bar id="bla" /> >> </bars> >> </foo> >> >> (which makes sense structurally) the result for the more general XPath query >> './/bar' will still contain only wanted elements, namely still only <bar >> id="baz" /> and <bar id="bla" />. It could be further refined by using >> /bars[1] as *context node* (using '.' in the path), referring only to nodes >> *below* that node in the hierarchy of the data structure. This is what I >> referred to with flexibility. >> >> IOW: Using the full XPath path is _not_ always the best approach. >> > > Once again you're as full of crap as your code is full of holes. But I > should know better than to try to teach the troll. It's like trying to > teach a pig to sing. > *yawn*
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.php
csiph-web