xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elchanan Shor <s...@textray.com>
Subject Re: XML Inheritance Extentions (first try)
Date Mon, 20 Dec 1999 09:15:53 GMT
Hi,

It might be useful to allow deletion of original elements (not only
overriding). This way it we are not interested in the legal element in the
output document (not a good example) we can do it.

Elchanan

Stefano Mazzocchi wrote:

> 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