xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Box, Don" <d...@develop.com>
Subject RE: XML Inheritance Extentions (first try)
Date Mon, 20 Dec 1999 03:36:20 GMT
I am not sure what this proposal buys that using the 'default', 'source' and
'restrictions' facilities of W3C XML schemas couldn't achieve (see
http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/)? In
XML Schemas, one can set up not only a 'type' definition, but also its
initial values. The 'source' attribute allows one to establish type
relationships via inheritance. The 'restrictions' element allows you to
alter the requirements of a type by constraining the values used in derived
types.

Here's a rough translation of your example to schemas:

<schema targetNamespace='http://www.apache.org/httpd/'
	  xmlns='http://www.w3.org/1999/XMLSchema'
>
	<type name='server'>
		<element name='type' type='string' default='standalone' />
		<element name='root' type='string' />
		<element name='pid' type='string' default='logs/httpd.pid'
/>
		<element name='scoreboard' type='string'
default='logs/apache_status' />
		<element name='timeout' type='non-negative-integer'
default='300' />
		<element name='keepalive' type='string' default='on' />
<!-- all the other default configurations as in httpd.conf -->
<!-- httpd:module stuff elided because I wasn't quite clear on the
information set -->
	</type>
	<element name='server' type='server' />
</schema>

then we have our conf file as simply

<httpd:server xmlns:httpd='http://www.apache.org/httpd/'>
    <httpd:root>/home/www</httpd:root>
<!-- httpd:module stuff elided because I wasn't quite clear on the
information set -->
</httpd:server> 
 
Note that the content of the root element is populated with the defaults
from the schema definition. A similar set of defaults could be established
for the module-specific stuff as well. If you want to flesh this out more,
I've been pretty immersed in the schemas stuff lately and would love to
pitch in.

DB
http://www.develop.com/dbox


> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Sunday, December 19, 1999 4:22 PM
> To: Apache XML; ASF Members
> Subject: XML Inheritance Extentions (first try)
> 
> 
> 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