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 06:54:27 GMT
I fundamentally believe that validation is one of the least interesting uses
of XML Schemas. Along those lines, the lack of validating parsers doesn't
necessarily impact the applicability of XML Schemas. The fact that the WD
hasn't gone to PR or CR yet is far more problematic than the lack of support
in Xerces et al.

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


> -----Original Message-----
> From: Brett McLaughlin [mailto:bmclaugh@algx.net]
> Sent: Sunday, December 19, 1999 10:43 PM
> To: general@xml.apache.org
> Cc: ASF Members; 'stefano@apache.org'
> Subject: Re: XML Inheritance Extentions (first try)
> 
> 
> 
> 
> "Box, Don" wrote:
> > 
> > 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.
> > 
> <example-snipped/>
> > 
> > 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.
> 
> I have a couple of problems with the schema method.  
> 
> First, it is not widely supported yet, and when it is (re: 
> Xerces) there
> are lots of features that aren't fully implemented.  This makes using
> XML Schemas practically difficult if not impossible (today).
> 
> Second, some of the default values you would have to set up would be
> absolutely meaningless.  For example, the <body/> tag in Stefano's
> orginal example.  I firmly believe that default values should be just
> that: defaults that have meaning, not placeholders to 
> accomplish another
> value (which is what they would be if used in this manner).  They lose
> any significance.  In addition, it becomes impossible to tell what
> values are truly defaults, and what are placeholders to allow
> extensions.  Finally, XML Schema is inherently about constraining XML
> documents.  I for one am uneasy with the multitude of 
> purposes they are
> already being applied towards, as it makes the processing necessary
> heavier and heavier.  Schemas shouldn't be the end-all 
> solution as many
> people are trying to make them; they should constraing XML, 
> period.  Let
> others specs handle other tasks.
> 
> Third, many good frameworks (re: Cocoon) allow validation to be turned
> off at production time.  This is very nice - development can 
> occur with
> validation on, and once document validity is ensured, validation of
> these program generated XML documents can be left out, resulting in
> _significant_ processing time increases.  The validation serves no
> purpose at that stage if the inputs and outputs are known and good
> white-box and black-box testing have occurred.  This also allows XML
> parsers to avoid having to resolve all external references, which aids
> speed and performance a lot when a DTD or Schema may have to be loaded
> across a network via URL.  An extension to the core XML language would
> allow extensions to take place without needing to add back in these
> external references or validation, while using XML Schema and defaults
> would force this validation/referencing to occur [again].  This also
> hearkens back to my second reason, in that XML Schemas are no longer
> constraining data, but defining it.
> 
> -Brett
> 
> > 
> > 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