Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:7044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 13 Jan 2004 02:52:37 -0500 (EST)
To: internals@lists.php.net
Message-ID: <Pine.LNX.4.58.0401130248410.21920@miranda.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: SimpleXML: Moving Forward
From: adam@trachtenberg.com (Adam Maccabee Trachtenberg)

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!