SimpleXML: Moving Forward
| From: | Adam Maccabee Trachtenberg | Date: | Tue, 13 Jan 2004 07:52:37 +0000 |
| Subject: | SimpleXML: Moving Forward | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-7044@lists.php.net to get a copy of this message | ||
In the hopes of moving the discussion forward, I'm going to try and
sum up general consensus. I believe we agree on most issues, so
hopefully it should be easy to come up with the next steps we should
take with SimpleXML.
I know it's late in the PHP 5 process, but I feel that SimpleXML was
designed in somewhat of an ad-hoc manner and has only now reached the
point where we have enough experience using it to really know where
the troublesome issues lurk. (Build one to throw away.)
Since there hasn't yet been a final release of SimpleXML, this is our
last chance to make these changes without worrying about BC and it's
worth a little trouble to get things closer to right earlier rather
than later.
Here's where I think we stand, with the points descending from top to
bottom in order of general agreement. (e.g. We all agree on point #1
and not everyone agrees with point #6.)
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']).
2) It is important to honor the Simple in SimpleXML. SimpleXML will
not try to replicate the entire DOM using an alternative
syntax. Instead, it will implement a "reasonable" (as of now
deliberately vaguely defined) subset of XML manipulation
functions. People who want more comprehensive features can use DOM.
3) This subset will attempt to be as minimalistic as possible, to keep
the core small. (e.g. Use XPath.) However, common actions will have
an alternative interface when they make SimpleXML easier to
use. (e.g. Implement getChildren() and getAttributes() functions.)
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.)
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.)
5) There will be a procedural interface for SimpleXML because nobody
is actively against this, Sterling is strongly for this, and
Sterling is willing to code it. :)
6) There will be an OO interface for SimpleXML because everybody
except Sterling is for this and because it already exists. :)
Okay, this message is too long, so I will end it now.
If we can get a couple +1s on this, I would then like to move onto the
next steps which would be deciding which functions will be in the
initial release, what their prototypes are, and who should implement
what and by when.
If you have problems, please rebut in line. Please try to be brief,
I'm wordy enough for everyone. :)
-adam
--
adam@trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!