I agree with Sterling that we should keep things simple and slim. This will also allows us to regret this decision in the future and add more functionality. As I said previously, I would however want to see a few methods which are still simple and extremely useful, so that in the common case people won't need to convert the SimpleXML object to DOM.
But seriously, let's move fast on this. It's not right to delay RC1 if people aren't giving this their best shot.
Andi
At 02:52 AM 1/13/2004 -0500, Adam Maccabee Trachtenberg wrote:
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
-- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
