Re: Package Proposal XML_Parser_Assoc

Trying to find the best aproach to an XML parser, we are forgetting the follow 3 situations: 1 - We want to parse an XML that we don't know nothing about it 2 - we want to parse an XMl that we know how it can be, but we don't know how exactly it is 3 - we know exactly how it is. let's use the follow xml to try all the 3 aproach above <family>

        <father name="Marcos" age="23" />
        <mother name="Patricia" age="26" />
        <childrens>
                <paul>I'm Paul</paul>
                <mary>I'm Mary</mary>
        </childrens>

</family> 1) using the first situation, as we don't know how the xml is, we need a class that implements the follow methods $class->parse($xml); // build from a xml string or file $class->getAtributes(); // an map array with the atributes $class->elements(); // the same as above $class->getData(); // return the CDATA this way, we can walk throw the tree. XML_Tree uses this aproach (I think!) 2) The second situation, that I thing is missing in XML_Unserializer and others classes. the class would be like this: The first method we set an schema for the class, so we could still have an empty xml, but with all properties like this: $schema = " <family>

        <father name="string" age="number">
        <mother name="string" age="number">
        <childrens></childrens>

</family> "; $class->setSchema($schema); $class->parse($xml); the data would be $family: object $family->father: object $family->mother: object $family->mother->name and ->age // the same for father $family->childrens: array you see that even if <childrens> is empty, has 1 or more, or even inexist, we still have the childrens vector, thanks to the schema XML !!! 3) this aproach is what XML_Userializer. Since childrens data type is always changes dependent on xml. I Hope this help to find the way now... I preffer implement new features in an existent package instead of adding new one to the repository. At 11:27 31/1/2004 +0100, Stephan Schmidt wrote:

Hi, What my package specifically does different is: * segregates attributes and sub-elements into different assoc arrays -This is good because attributes are unique while sub-elements are not * Always puts sub-elements into an array. -This allows for one way to access elements instead of multiple ways. You don't have to do an is_array() to see if an element has multiples before you try to access it. You can still access a specific element easily: $subElem = (is_array($elem['subElem']) ? $elem['subElem'][0] : $elem['subElem']) in XML_Unserializer would be $elem['subElements']['subElem'][0] with the new package OR XML_Parser_Assoc::getElement($elem['subElements'], array('subElem')); * CData in an element with sub-elements is picked up, unlike XML_Unserializer I could easily integrate these features in XML_Unserializer so you can switch between the two behaviours. So I don't think that this package should be integrated in PEAR as it duplicates functionality. Stephan -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php