xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject XML Inheritance Extentions (first try)
Date Mon, 20 Dec 1999 00:21:55 GMT
Hi,

here is my first try to define what I called the "XML Inheritance
Extentions". This document should be considered a rough request for
comments that will hopefully lead us to have a useful and
well-integrated note to be submitted to the W3C for review.

Comments, suggestions and questions are encouradged and deeply welcome.

[Copied to the ASF members since it may also impact the XML
configuration effort for Apache 2.0]

------------------------ cut here ----------------------------------

                XML Inheritance Extentions

                            by
                     Stefano Mazzocchi
                    <stefano@apache.org>


Introduction

  The XML model, term that will be used to indicate the XML
specification together with all the other XML-related W3C
specifications, is currently lacking of O-O abilities such as
inheritance.

  This note wants to propose extentions to the current XML model to
allow an XML document to "extend" another one, "inheriting" parts of the
extended document and overriding other parts.


Impact on the existing model

  In the XML model there already is a notion of inheritance,
specifically in the "import" element of the XSLT language that allows
one stylesheet to inherit part of the behavior of another stylesheet.

  Unfortunately, this behavior cannot be applied to a general XML
document and this is the reason why this note was proposed.


General Goals

  Following is a summary of the design principles governing this
proposal:

- should integrate completely with existing W3C recommendations and
working drafts 
- should not aim to replace existing technologies, rather, to make the
notion of inheritance available to the whole XML model
- should not aim to create yet another transformation language
- should be aimed to document writers:
    o  the learning effort should be minimal
    o  the flow should be document-driven (i.e. not XSLT-like)
    o  reduced verbosity is of maximal importance
    o  clarity and self-explanation is of maximal importance
- should be helpful
- should follow existing O-O design patterns regarding inheritance
- should not try to solve all the world problems (read: keep it simple!)
:)


Modelling from existing solutions: Java principles of inheritance

  The Java Programming Language has built in inheritance principles with
the notions of "a class extending another class" and "an interface
extending another interface". In the object oriented world,
"inheritance" means that object B extending object A, inherits all
object A's properties and it's able to:

  - add new ones.
  - overwrite existing ones (thus changing them).

  This note follows the same design pattern. Document B extending
Document A should inherit all document A properties and extend/overwrite
them at need. 

  The goal we want to achieve is evident: The notion of inheritance
allows clean separation between general documents (also referred to as
"templates" or "forms") and their specialiations/completions. 
  It must be noted this pattern is, somewhat, an extention or the
simpler "inclusion" pattern used, for example, for entities, parsed
XLinks and in the XInclude proposal and, in our opinion, better suited
for some uses of common and general interest.


A working proposal

  Let us suppose we have a template XML document that looks like this:

<page>
  <title/>
  <author>John Smith</author>
  <body/>
  <legal>Copyright (c) 1999 John Smith. All rights reserved.</legal>
</page>

  We would like our document to "extend" the template one to "inherit"
some of its structure, allowing to minimize content replication and to
centralize a point of update that gets automatically reflected to all
the extending documents.

  For example, a final document is something like this:

<page>
  <title>Home Page</title>
  <author>John Smith</author>
  <body>
   <p>Hi, welcome to my home page.</p>
  </body>
  <legal>Copyright (c) 1999 John Smith. All rights reserved.</legal>
</page>

  where we clearly see major overlap between the two documents.

  Let's try with the following document:

<page xml:extends="template.xml">
  <title>Home Page</title>
  <body>
   <p>Hi, welcome to my home page.</p>
  </body>
</page>

  might be transformed in the one above with a simple "merging"
algorithm that "overwrites" existing elements (in their locations) with
the elements (and their substructure) defined in the extending document.


Limitations of the above model

  The above model it's very simple but has some limitations:

- elements cannot be added but only replaced
- there is no notion of order for the elements added that don't extend
elements defined in the template document.

  The first limitation is removed with the addition of the "overwrites"
notion:

<page xml:extends="template.xml">
  <title>Home Page</title>
  <author xml:overwrites="false">Jane Smith</author>
  <body>
   <p>Hi, welcome to my home page.</p>
  </body>
</page>

  considering all nodes with 'xml:overwrites="true"' by default.


Structure inheritance

  The examples above follow very simple schemas, but inheritance should
work at all levels and should not impose restrictions on schemas. The
outlined notion of document inheritance must be visualized as a "fill
the blanks" approach, were the extending document copies the original
structure adding or overwriting items (elements/attributes) in the
extended document at need.

  A more complex example should clarify this further:

  <httpd:server id="Apache" xmlns:httpd="http://www.apache.org/httpd/">
   <httpd:type>standalone</httpd:type>
   <httpd:root/>
   <httpd:pid>logs/httpd.pid</httpd:pid>
   <httpd:scoreboard>logs/apache_status</httpd:scoreboard>
   <httpd:timeout>300</httpd:timeout>
   <httpd:keepalive>on</httpd:keepalive>

   <!-- all the other default configurations as in httpd.conf -->

   <httpd:module id="jserv_module" 
                 object="modules/mod_jserv.o" 
                 xmlns:jserv="http://java.apache.org/jserv/">

    <jserv:automatic enabled="true"/>
    <jserv:properties/>
    <jserv:log level="notice"/>
    <jserv:authentication enabled="false"/>

    <jserv:mount from="/servlets" to"ajpv12://127.0.0.1:8007/root"/>
    <jserv:mount from="/servlet" to"ajpv12://127.0.0.1:8007/root"/>
  
    <jserv:action match="*.xml"
call="/servlet/org.apache.cocoon.Cocoon"/>
  </httpd:module>
 </httpd:server>

than we have our conf file as simply

  <httpd:server xml:extends="apache-conf-template.xml">
   <httpd:root>/home/www</httpd:root>
   <httpd:module id="jserv_module">
    <jserv:properties file="/apache/jserv/conf/jserv.properties"/>
    <jserv:log file="/apache/logs/mod_jserv.log"/>
    <jserv:authentication enabled="true"
key="/apache/jserv/conf/secret.key"/>
   </httpd:module>
  </httpd:server> 

which creates

  <httpd:server id="Apache" xmlns:httpd="http://www.apache.org/httpd/">
   <httpd:type>standalone</httpd:type>
   <httpd:root>/home/www</httpd:root>
   <httpd:pid>logs/httpd.pid</httpd:pid>
   <httpd:scoreboard>logs/apache_status</httpd:scoreboard>
   <httpd:timeout>300</httpd:timeout>
   <httpd:keepalive>on</httpd:keepalive>

   <!-- all the other default configurations as in httpd.conf -->

   <httpd:module id="jserv_module" 
                 object="modules/mod_jserv.o" 
                 xmlns:jserv="http://java.apache.org/jserv/">

    <jserv:automatic enabled="true"/>
    <jserv:properties file="/apache/jserv/conf/jserv.properties"/>
    <jserv:log level="notice" file="/apache/logs/mod_jserv.log"/>
    <jserv:authentication enabled="true" 
                          key="/apache/jserv/conf/secret.key"/>

    <jserv:mount from="/servlets" to"ajpv12://127.0.0.1:8007/root"/>
    <jserv:mount from="/servlet" to"ajpv12://127.0.0.1:8007/root"/>
  
    <jserv:action match="*.xml"
call="/servlet/org.apache.cocoon.Cocoon"/>
  </httpd:module>
 </httpd:server>


Merging rules

 The whole standardization (and discussion) effort should go in defyning
the algorithmical rules that create the merging.

 Here is a quick and dirty set of rules (these need more more work!):

1) if an element is found with same name, same id and same position, the
resulting element is the merge of the two. Then the extending element is
not further used.
2) if an element is found with same name, same position but no id is
specified, the extending element is merged with all elements found in
the same position.
3) if an element is found with same name, same position and
"overwrite=false", the extending element is added and the original
elements are copied over.
3) if no element is found with same name and same position, the element
is copied at the current cursor position.

  Merging of two elements is defined as follows:

a) create a vector of attributes from the original element, add all the
attributes of the extending element, overwriting attributes with same
name.
b) for each element of the original element, apply the first three
merging rules.


Conclusions

  The paper outlined a proposal to allow XML inheritance adding just
"two" attributes in the reserved "xml" namespace. While the namespace of
these attributes is of very little importance, we wish to be able to
have such a powerful functionality in the XML model without requiring
the full power of a transformation language.

  In fact, while the funtionalities needed in this paper are already
available in the XSLT language, the required syntax and complexity is
incredibly higher, reducing readability and placing an higher energy gap
to allow general document writers to use such important separation
features.


Further work

 -  The "Merging rules" section must be rewritten to be much more
formal.
 -  Overlapping with existing standards/proposals (the "SGML Application
Forms" proposal) should be examined.
 -  feedback must be fed back into this note for a second try.

------------------------ end of document ------------------------

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message