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.
Tuesday, January 13, 2004, 8:52:37 AM, you 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! -- Best regards, Marcus mailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
