generating code from xml schema documents

James Miller wrote:
> Tod Harter <thartergiantelectronicbrain.com> writes:
> [...]
>   
>> It seems to me that validation prior to processing
is more the answer 
>> there, in the case where perl is consuming XML. If
the document isn't 
>> valid, don't process it, if it IS valid, then
presumably your types are 
>>     
>
> This has been my experience.  My latest project
involves maintenance of
> complex data trees which drive a web application.  The
application reads
> these trees out of a RDBMS, but the domain experts who
build the trees
> prefer to create and modify them in a spreadsheet
processor, although
> they'll sometimes edit live data, too.  I use
home-rolled XML
> representations as the "canonical"
serializations of these trees,
> principally to verify that the trees' forms and
content won't blow up
> the web application.  The RELAX NG schemas I use are
expressions of the
> application's expectations, not of my Perl ETL (for
lack of a better
> term) code's expectations.  The hairiest part of the
Perl code is the
> XML->DB transform; knowing that incoming XML is
valid allows me to make
> some simplifying assumptions in this code, but the XML
schemas
> themselves don't say diddly about how the XML is
mapped to the SQL
> schema.
>   
> Yes, again.  Actually I've been groping around in my
code for a way to
> uniformly express the XML<->SQL mappings, but
haven't hit on a general
> solution yet.  
Hmmm, well, here's what I did (and I have code, though it
isn't CPAN 
quality)...

I built a 'mapping' file, which basically is an XML file
like so:

<fm:bindings name="binding test"
        xmlns:fm="http://xm
l.giantelectronicbrain.com/NS/form"
        >
        <fm:binding>
                
<fm:form>/fm:defaults/fm:fields/fm:input[name='projectid']/fm:value</fm:form>
               
<fm:data>/database/select/row/projectid</fm:data>
;
               
<fm:request>/formdata/projectid</fm:request>
                <fm:type label='Project ID' 
null='OK'>nonNegativeInteger</fm:type>
                <fm:message>$label is an incorrect key
value</fm:message>
        </fm:binding>
        ...
</fm:bindings>

Each fm:binding tag specifies a set of XPath statements 
relating  in 
this case 3 things, the position of an element in an XML
form 
definition, the binding of the data in an XML representation
of the 
result set of a corresponding SQL query, and the position of
the 
returned form data in an XMLized version of the HTTP
response from the 
client. In addition some other metadata is available. The
same kind of 
approach (and the same code module) will work for binding
data between 
any 2 XML documents, assuming they have the appropriate
structure. The 
database XML can be fed back into the system to generate an
insert or 
update query. It took a couple weeks of coding, but the
result is quite 
flexible. I can now implement ANY form I want simply by
creating an XML 
form definition, a binding file, building the database
schema, and 
implementing whatever XSLT you want to use to insert the
form into HTML 
to present to the client. Adding in a few 'plugin'
capabilities gives a 
front processor style web application that can handle all
the nitty 
details like rending pick lists of related objects, tables,
multi page 
conversations (wizards) etc. . The same
code has ETL type applications 
as well.
> When you get even more general than just an
XML<->SQL
> mapping, that is, try to generate _semantics_ from a
grammar (XML
> schema), you fall off the edge of the earth, because
XML schema
> languages aren't up to that task and really aren't
meant to be.  Besides
> some little stubs, the only useful code that could be
generated from an
> XML schema would probably be a validator hardwired to
that one schema --
> in other words, you'd have a sort of XMLish yacc. 
You'd still have to
> hang code that does useful stuff on hooks in that
generated code.
>   
Yep, that would be a useful tool.
>
____________________________________________________________
____________
>
>                      James Miller in Austin, Texas
>
____________________________________________________________
____________
>
> _______________________________________________
> Perl-XML mailing list
> Perl-XMLlistserv.ActiveState.com
> To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs
>   

_______________________________________________
Perl-XML mailing list
Perl-XMLlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs