SimpleXML: Moving Forward View as Markdown

Rob Richards wrote:

From: Adam Maccabee Trachtenberg

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']).

Hmm... This is somewhat up-side-down language wise. Attributes are
properties of a node and the node contains children like an array
contains elements. But I guess we'll keep it that way for nesting sake
($foo->foo2->foo3 is so much nicer than $foo['foo2']['foo3']).

But let's take a look on how I'd use it (xml formatted for readability):
$foo = simplexml_load_string('
<foo x:a="xa" y:a="ya">
ab
<foo2>foo2a</foo2>
cd
<foo2>foo2b</foo2>
ef
<foo3>
foo3
<foo4>foo4</foo4>
foo3
</foo3>
gh
</foo>');

foreach ($foo as $node) => foo2a foo2b foo3
foreach ($foo->foo2 as $node) => foo2a foo2b
foreach ($foo->foo3 as $node) => foo4
foreach ((array)$foo->foo3 as $node) => foo4
foreach ($foo->foo3->foo4 as $node) => nothing
foreach ((array)$foo->foo3->foo4 as $node) => foo4

What seems wrong here is that to output nodes where there can be 0 to
multiple instances I have to do something like:
if ($foo->$nodename)
{
if (is_array($foo->$nodename))
{
foreach ($foo->$nodename as $node)
echo "$node\n";
}
else
echo "{$foo->$nodename}\n";
}
else
echo "No node $nodename found\n";

$nodename = 'node1' => No node node1 found
$nodename = 'node2' => foo2a foo2b
$nodename = 'node3' => foo3

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">

Right now foo['bar'] will be an array('x', 'y') in that case. We're
losing the namespaces here but get the values. Simple or broken? Not sure.

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.

I agree. What about getChildren($level = 1) with $level=0 meaning all?
This offers both functionalities while having a default we decide on.

As right now there is no easy (read non-xpath/xquery) way of getting the
attributes hidden in the magic array of $foo I think getAttributes
should be added too.

No other functions though. Should these be methods? I think so.

$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";

I would actually expect abcd but only once:
Node Value: abcd

Concatenating all text parts and returning them once for each part
definitely seems wrong.

+1 on getChildren/getAttributes (function or method)
-1 on more functions

I think it's quite usable this way and simple enough to use to earn the
name SimpleXML.

• Chris

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?

Here's where I see the benefit of SimpleXML. SimpleXML should be used
when you know the schema of an XML document and want to extract
specific pieces of data from it. My favorite use-cases are: RSS, REST,
and configuration files.

This doesn't mean there's necessarily a formal XML Schema or RelaxNG
document, but that the developer is familiar enough with the layout of
the XML document that she knows what she's looking for and can
formulate code to access the information she wants.

In most cases, this will be through directly accessing text nodes
through $foo->bar->baz. More complex cases will be handled using XPath:
/rss:foo[begins-with('dc:bar', '2004-01')]/rss:baz.

In my ideal world, you can use SimpleXML for all XML documents,
regardless of complexity (read: namespaces, right?). However, if this
lead to an unnecessary amount of complexity, I would sacrifice this
point.

Also, since there's some assumption of developer fore-knowledge of the
document's schema, there's no need for an overwhelming set of
introspection functions, since that's where DOM excels.

To sum up: it would be helpful to see some real world XML documents
that people want to parse using SimpleXML.
We'd then try very hard to make sure SimpleXML was easy to use for
those documents. It's easy to make up theoretical XML documents that
are well-formed and pathologically nasty, but it'd much prefer to leave
those to DOM.

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.

Ugh. That's nasty. I would prefer to not handle this in SimpleXML. Have
you really even seen a case where someone did this?

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.

I agree here.

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).

I also agree here. This is one of the reasons I feel it's important to
hash out these details now, so that all the functions work
consistently.

I would prefer to always return an array (or a SimpleXML_List object
that's similar to DOM nodeList) of SimpleXML objects from any querying
function, whether it's getChildren(), getAttributes, or xPathQuery(). I
think this is most consistent.

For example:

Therefore, $xml->xPathQuery('/foo/bar') and $foo->getChildren() (and
maybe $foo?) would be equivalent.

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?

Honestly, I don't think anyone (read: I) never considerer that
SimpleXML would be used in cases that mix text and element nodes. I
never encountered this in my use-cases from above.

Currently, I believe the SimpleXML document model assumes that an
element contains (zero or more elements) or (one text node). So, if you
take your XML example from above and do:

print $foo

You get:

abcd

There's no way to access "ab" and "cd" as separate entities, so I would
almost say the consistent answer is to concatenate the two text nodes
from the XPath query and return just one text node, "abcd".

If you're looking for boundaries, I would tell you "Don't use SimpleXML
for this because it may not act as you expect."

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.

Does this bring us any closer to defining the boundaries? Would you
like them shifted? :)

-adam

--
adam trachtenberg
adam@trachtenberg.com

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">

Attributes should be ns qualified within the array:

$node->foo['a:bar']

This would respect namespaces "registered" by register_ns()

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.

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.)

I've decided (unless some more people pipe up support for removing
children() and attributes() its current 2-3 against) to leave children()
and attributes(), but remove the other methods. Things like schema
validation and xpath queries will become procedural.

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).

xsearch will become a procedure, simplexml_query($node, 'expression', $matches);

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?

Yep, this is the intended behaviour of simplexml. The
simplexml_save_string() function will allow you to get the entire node
contents (including tags). As for processing text childs separately,
use DOM. It can interpret the same results of an XPath query in the
manner you desire.

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.

Well, this is the purpose in finalizing the underlying API. The answer
to that question is simple, if it doesn't do what you want, then
SimpleXML is not what you want. This is part of the reason I want to
finalize on no methods. If you need methods, use DOM, the two are
totally interoperable, requiring zero document copies to work with both.
You can process a DOM object then load it into simplexml for the final
processing. Conversely you can take a simplexml object and load it into
DOM for complex processing.

I'm certainly stopping the API at children() and attributes(),
regardless, as anything else is just silly, and it seems that only
people felt strongly about these two functions. (*)

Schema validation and XPath searching will become functions in
SimpleXML space.

-Sterling

(*) Btw, getChildren() is currently broken from a userspace perspective
as it is mainly implemented for the SPL recursive iterator. This will
have to change, simplexml will not add userspace APIs for other
extensions.

Hello Adam,

Thanks for moving backward. Since iterating is now worthless i am all for
removing it completley. I mean it isn't even in the spirit of the extension.
I will sleep over this tonight and probably remove the work of another full
week too. Just because it is too complex and doesn't fit in the current
scheme of SimpleXMl.

Marcus - why remove iterators? Just because we remove their user level
API's, I see no reason to remove the internal implementations?

-Sterling

--
"Reductionists like to take things apart. The rest of us are
just trying to get it together."
- Larry Wall, Programming Perl, 3rd Edition

Marcus Boerger wrote:

Thanks for moving backward. Since iterating is now worthless i am all for
removing it completley. I mean it isn't even in the spirit of the extension.

Care to explain? I'm dazed and confused on how you came to the
conclusion that iterators are now worthless...

Was this discussed off-list? No message on the list seems indicating
that to me but maybe I missed it. Or I don't understand what you mean by
'iterators' or 'worthless'.

Wanting to understand your frustration,

• Chris