xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: XML Inheritance Extentions (first try)
Date Mon, 20 Dec 1999 14:17:47 GMT
Donald Ball wrote:
> 
> My proposed syntax differs somewhat from Stefano's. For the purposes of
> this document, I'll choose, uh, 'ixml' for its namespace:
> 
> <connection id="normal" driver="org.gjt.mm.mysql.Driver"
>             dburl="jdbc:mysql://mysql.example.com/test"/>
> 
> <querydefs name="options" doc-element="options" row-element="option"
>            tag-case="lower">
>  <column name="creation_date" format="MMMM d, yyyy"/>
> </querydefs>
> 
> <query>
>  <ixml:extends name="connection" id="normal"/>
>  <ixml:extends name="querydefs" id="options" id-element="name"
>                inherits-elements="true"/>
>  select * from foo_table
> </query>
> 
> would generate:
> 
> <query driver="org.gjt.mm.mysql.Driver"
>        dburl="jdbc:mysql://mysql.example.com/test"
>        doc-element="options" row-element="option" tag-case="lower">
>  <column name="creation_date" format="MMMM d, yyyy"/>
>  select * from foo_table
> </query>

???

Are you sure this is algorithmically certain? I can't visualize a
turing-machine that performs such generation, given the information you
provide. Am I missing something?

> The attributes allowed on the ixml:extends element would initially be:
> 
> href - to identify the location of an external XML document from which the
> logical parent would be culled (default: this document)
> name - the name of the logical parent element
> id - the value of the logical parent's id attribute
> id-attribute - the name of the logical parent's id attribute (default: id)
> inherits-attributes - true/false, inherit attributes from logical parent
> (default: true)
> inherits-elements - true/false, inherit elements from logical parent
> (default: false)

[...]

> Anyway, tangents aside, my proposal allows for polymorphism, independent
> inheritance of attributes and elements (and possibly text nodes), and a
> more finely controlled logical parent element selection.

Donald's proposal is more overlapping with XSLT in its linearized
(template-less) version.

I evaluated the use of "linear XSLT" for inheritance and found it too
much verbose, even if much more flexible. I think they solve totally
different problems even if inheritance is a kind of transformation so
you can always have an XSLT transform-sheet to do the kind of
inheritance you need. The problem is that this transform-sheet may not
be general enough for reuse with all extentions.

Donald proposal is half in between, but follows the "query and replace"
pattern that XSLT templates use, in a ligher fashion, perhaps. And I'm
not sure we want to reinvent part of that wheel...

Like Ben indicates, the posisition-driven approach might be more
difficult to manage, expecially since merging rules are hidden. On the
other hand, if these rules are kept simple and user-friendly (they do
what you expect from other inheritance patterns), verbosity is reduced
and visibility improves.

Also, having positional and structure limitations is not always a bad
thing: the Java architects imposed single inheritance since they
considered that more careful programming can _always_ remove the need
for multiple inheritance, which is much harder to manage. The first time
you hit this, you curse them, but after you learned how to get around
this, you thank them.

XML is a positional language, except for attributes. True, you can
choose to ignore the position information (even during validation), but
this is your choice, it should not be imposed as a general thing.

Also, answering Brett, the idea of dummy placeholders is not a bad one,
IMO, since it allows template writers to "visualize" the positions where
the extentions should be, simplifying development (something that XSLT
generally fails to provide, unless you use the template-less mode).

You should not confuse my proposal with a general separation language.
XSLT does a perfect job on that. If you want clean separation, use XSLT.
Inheritance is based on the idea of structured content reuse, rather
than separation of contexts.

Also, keep in mind that DTD validation can be generally done only as the
last operation, after merging is performed. The same DTD cannot be
generally used to validate original documents or their extentions.

-- 
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