XML binding & persistence library

From: Date: Mon, 15 Mar 2010 11:09:17 +0000
Subject: XML binding & persistence library
References: 1  Groups: php.gsoc 
Request: Send a blank email to [email protected] to get a copy of this message
*Description:* object-oriented library for mapping XML file structure,
binding to PHP 5 class. Library would provide functionality for using XML
based entity descriptions, described in XML Schema, to perform data
manipulations(CRUD facility), and would use described entity relations for
persisting XML entries. Association and/or aggregation would represent O-O
abstractions for XML entity relations. For performing queries would be used
either on-the-fly or automatically generated translation of XML entity
properties, characteristics to XPath expressions, which can give a
performance boost for production (read: non-development) usage. Also should
be implemented functionality for building XML formatters from XML Schema,
which itself avoids a lot of script execution speed reduction for preparing
& splitting together XML tree data structures

*Main implementation reasons and usage opportunities*:

   -

   Most of XML structures represent complex entries, where both nested tags
   and tag properties represent characteristics and behavior. This usually
   results in escalation of complexity of XML interpretation rules, code will
   be more heavy. Additional development penalty is that often such rules are
   less similar against each other – amount of reusable code is very low. Also
   data entries, related to entities with deeply nested relations, would
   require manipulation of a group of files as a single transaction to provide
   persistence; normally there is no way to reuse XPath queries in a way, that
   is entry based


   1.

      I have motivation to go even farther: iterators would act as a fork,
      moving back an forth (development stage) threw a set of tags and/or tag
      properties. Iterators can become reusable in different projects, for
      different XML structures, simply changing naming convention
(read: the way
      how the tag names, with respect to W3C qualified name features)
      2. Can help a lot in translating XML binding code threw XPath
      expressions (because of specific W3C specification rules, which
supposed to
      query all matched entries by default). Even possible to force
relations in
      generated XPath to speed up querying – a complex expression can
specify one
      rules before another (for example, if specific ancestor in XML tree would
      arrive less often then some tag property, it can be possible to mention
      ancestor requirement before property requirement – less line
count would be
      iterated*)


   -

   You could use PHP 5 reflection and O-O features of PHP 5 to describe
   classes. And after that you can simply generate required XML Schema. Awesome
   for using non-DOM (read: SAX) libraries at production environment,
   especially if there would be a mix of PHP 5 code and, say, Java code (by the
   way – code generator can produce code for other languages, if necessary).
   Good for situations where you should develop some administration tools with
   web interface in PHP 5, which would operate on Java software XML based
   configuration files (for example, XML configuration file for Java message
   broker)
   -

   Of course, the well known mixing of database mapping(ORM) and XML
   mapping. Would be awesome if there would be an import of ORM classes to XML
   related ones and vice versa – more flexible RDBMS table structure. Awesome
   for complex storage manipulations (storing objects and/or their entities in
   XML and RDBMS, without an performance penalty of forcing RDBMS to format XML
   for you). And, probably the most awesome here – you can move data from XML
   storage to RDBMS and vice versa for balancing load performance, especially
   if data characteristics can vary a lot. Generation of performance tests can
   be added if necessary
   -

   XML web site maps. Yea, those are often in XML. Also their CMS systems,
   that can manage site structure threw XML. And because MVC frameworks are
   most wide solution – the site map itself is referred (directly or not) to
   controller class – action name pairs. As a result – it is hard to forget
   about automatic testing, that is where PHPUnit can come up. Main idea – use
   site map as a prototype for defining more complex mapping. Some kind of XML
   tree with entities described (entries are referred to controller-index
   pairs, remember), where entities described in a test feature driven manner;
   you can force your testing automation with a guaranty of covering necessary
   QA features, even connect QA software to development tools. Note: DOM
   library would be used at background due to complexity of testing
   configuration
   -

   And, of course, the famous RESTful Web services ;) At least can help in
   data deduplication...


Thread (2 messages)

« previous php.gsoc (#151) next »