Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7047
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <00fe01c3d9d1$6e8618a0$f7dea8c0@cyberware.local>
To: "Adam Maccabee Trachtenberg" <adam@trachtenberg.com>,
   <internals@lists.php.net>
References: <Pine.LNX.4.58.0401130248410.21920@miranda.org>
Date: Tue, 13 Jan 2004 07:33:16 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SimpleXML: Moving Forward
From: rrichards@ctindustries.net ("Rob Richards")

From: Adam Maccabee Trachtenberg

> 1) SimpleXML creates PHP data structures from XML documents. It only
>    handles XML elements, attributes, and text nodes. The syntax for
>    accessing the text node children of an element is akin to object
>    properties ($foo->bar); the syntax of accessing attributes is akin
>    to array elements ($foo['bar']).

This goes back to my question on what is the goal of SimpleXML?
Is it supposed to be an easy api to be able to access any xml document or
only not complex ones?
Attributes are handled associative arrays, so given an element with 2
attributes with the same name, but in different namespaces, it wont work:
<foo a:bar="x" b:bar="y">

xpath wont help here either as xsearch returns an array of sxe objects with
the attribute nodes (which causes some additional problems).
Its fine if this would have to be handled in dom, but to me the question
really has never been fully answered.
See also example under the xpath comments for elements containing mixed text
and element nodes.

>    When deciding the behavior of these functions (e.g. Does
>    getChildren() return just the direct descendents or all children
>    regardless of depth?), we'll define them to mimic XPath's behavior:
>    (e.g. /child::node()). This reduces the potential for disagreement
>    over what is the "correct" way to do things. (I'm just looking for
>    a way to prevent protracted discussions over issues that have no
>    clear "right" answers and can never really be solved.)

Should only be direct descendants. One should be able to navigate the entire
tree (elements/attributes) in a standard way without having to use xpath.
imho, this is one of the biggest reason why the two functions should be
implemented.

>
> 4) XPath and validation functions will be available in SimpleXML, but
>    we will not try to code generic extensions that work with both
>    SimpleXML and DOM if for no other reason than this is not
>    guaranteed to be simple. (e.g. SimpleXML must remove from XPath
>    results nodes that aren't elements, attributes, and text nodes.)

return types need to be standardized. attributes or getAttributes returns
name/value array, while the current xsearch will return array of a sxe
objects of the attribute node (which stated before is bad in the current
state of simplexml).

Also, consider the following (an element contains a mix of text and element
nodes):
$foo = simplexml_load_string('<foo>ab<foo2>test</foo2>cd</foo>');
$ns = $foo->xsearch('child::text()');
foreach ($ns as $node) {
 print "Node Value: ".$node."\n";
}

Output:
Node Value: abcd
Node Value: abcd

One would expect:
Node Value: ab
Node Value: cd

Is the output correct, should something like this not be handled via
simpleXML, or is the xsearch incorrect when it returns the parent of a text
node?

Your initial point concerning what SimpleXML is was a good start, but it
still doesn't define the boundaries of what it is meant to handle. When do
you tell someone that what they are doing should not be done in SimpleXML?
This is where I get lost with the API as I don't really know its intended
limitations.

Still +1 on the getChildren/getAttributes.

Rob