generating code from xml schema documents

On Tue, 16 May 2006, Miller, Hugh (hdmi) wrote:

> I am interested in the problem of writing perl code
that will take an
> xml schema document and generate a perl reader (with
stubs for callbacks
> for the various elements) that will handle any xml
documents that
> conform to the schema.
>
> Can anyone advise me concerning work that has been done
on this problem
> or variants thereof ?

Some progress has been made on a pure-Perl XML Schema
validator:

    http://search.cpan.org/~samtregar/XML-Validator-Schema

It already does a little code generation to deal with
constraints.
I'd love to have some help improving its spec coverage.  If
that was
accomplished via code-generation I think that would be fine!

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

On Tue, 2006-05-16 at 17:24, Miller, Hugh (hdmi) wrote:
> I am interested in the problem of writing perl code
that will take an
> xml schema document and generate a perl reader (with
stubs for
> callbacks for the various elements) that will handle
any xml documents
> that conform to the schema.
> 
> Can anyone advise me concerning work that has been done
on this
> problem or variants thereof ?

This is something that I have been thinking about quite a
bit recently,
the specific use case I have is for accessing
document/literal  SOAP
services defined in WSDL.  Part of the problem I have in
envisaging how
this would best be done is the Perl's dynamic nature:
whereas in, say,
c# you can take some XSD and create a set of classes into
which an
instance of the XML can be 'deserialized' in a standard
manner, in Perl
there is no standard way of representing the structures in
classes or
otherwise (I'm assuming a ComplexType to class mapping as
in .NET here).

I guess in the end it's take the Schema Parser and JFD the
code
generation parts and create a de-facto standard, but if
anyone has any
ideas about this that can nudge me out of my doubt and
uncertainty and
actually do something about it I would be keen to here them.

/J\
-- 

This e-mail is sponsored by http://www.integrat
ion-house.com/

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

On Wed, 17 May 2006, Jonathan Stowe wrote:

> Part of the problem I have in envisaging how this would
best be done
> is the Perl's dynamic nature: whereas in, say, c# you
can take some
> XSD and create a set of classes into which an instance
of the XML
> can be 'deserialized' in a standard manner, in Perl
there is no
> standard way of representing the structures in classes
or otherwise
> (I'm assuming a ComplexType to class mapping as in
.NET here).

I don't see this as a major challenge - plenty of other
projects have
dealt with similar problems successfully.  For example,
Class:BI
(with the help of loaders like Class:BI::Load
er) produces a flexible
and relatively standard class hierarchy based on an SQL
schema.  That
looks pretty similar to the job of someone trying to create
a class
hierarchy capable of loading data from XML described by an
XML Schema.

Your major challenge is the lack of a complete
spec-compliant XML
Schema processor.  Want to help?  XML::Validator::Schema is
waiting
for you!

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

Perl IS virtually infinitely plastic in terms of structuring
objects. 
You just have to make SOME decisions about exactly what you
want to be 
able to support... Realistically you decide on a likely
object 
representation and go from there. I guess I'm also not 100%
sure what 
would be defining your mapping or exactly what types of
mappings you are 
thinking of supporting. It shouldn't be too tough to
develop a SAX based 
mapping system, for example, but would your tool map any
possible Schema 
in an arbitrary way onto an object? How do you actually
define what gets 
mapped where?

I built a pretty decent module that took an XML input file
and a perl 
hash-based object plus a mapping file that simply uses an
XPath 
expression to map from XML to object, it was fairly simple
actually... 
(well, a week of work to make it nice). But XSD didn't
factor in there 
except it did have a feature that let you define the XSD
data types 
allowed for elements (IE you could validate that what you
were getting 
was a number using an XML data type notation). It didn't
even seem 
necessary (or maybe desirable) to do any code generation,
though it 
might be possible to get some performance if you did. I'm
just not sure 
where a schema adds a lot, given that perl is pretty close
to typeless 
anyway.

I think the main reason not a lot of tools of this type
exist in perl is 
just that most of us don't NEED them all that badly.

Sam Tregar wrote:
> On Wed, 17 May 2006, Jonathan Stowe wrote:
>
>> Part of the problem I have in envisaging how this
would best be done
>> is the Perl's dynamic nature: whereas in, say, c#
you can take some
>> XSD and create a set of classes into which an
instance of the XML
>> can be 'deserialized' in a standard manner, in
Perl there is no
>> standard way of representing the structures in
classes or otherwise
>> (I'm assuming a ComplexType to class mapping as in
.NET here).
>
> I don't see this as a major challenge - plenty of
other projects have
> dealt with similar problems successfully.  For example,
Class:BI
> (with the help of loaders like Class:BI::Load
er) produces a flexible
> and relatively standard class hierarchy based on an SQL
schema.  That
> looks pretty similar to the job of someone trying to
create a class
> hierarchy capable of loading data from XML described by
an XML Schema.
>
> Your major challenge is the lack of a complete
spec-compliant XML
> Schema processor.  Want to help? 
XML::Validator::Schema is waiting
> for you!
>
> -sam
> _______________________________________________
> 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

On Wed, 2006-05-17 at 22:50, Tod Harter wrote:
> I'm just not sure where a schema adds a lot, given
that perl is pretty
> close to typeless anyway.
> 

Sure, but the problem arises where a Perl program or library
needs to
inter-operate with one written in a strongly typed language
using XML
messages that are defined in an XML Schema Definition.  The
way I see it
in this context the best approach might be to fake up some
typedness on
the part of Perl.

> I think the main reason not a lot of tools of this type
exist in perl is 
> just that most of us don't NEED them all that badly.

The reason that I think we do need it is to properly support
WSDL which
is the formal definition of an interface which is
implemented via XML
messages which can be (in the document/literal case that
most of the
major players advocate) defined as XML schema. I'll leave
the discussion
on why we need Perl to properly support WSDL for the time
being.

/J\
-- 

This e-mail is sponsored by http://www.integrat
ion-house.com/

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

On Wed, 2006-05-17 at 21:48, Sam Tregar wrote:
> On Wed, 17 May 2006, Jonathan Stowe wrote:
> 
> > Part of the problem I have in envisaging how this
would best be done
> > is the Perl's dynamic nature: whereas in, say, c#
you can take some
> > XSD and create a set of classes into which an
instance of the XML
> > can be 'deserialized' in a standard manner, in
Perl there is no
> > standard way of representing the structures in
classes or otherwise
> > (I'm assuming a ComplexType to class mapping as
in .NET here).
> 
> I don't see this as a major challenge - plenty of
other projects have
> dealt with similar problems successfully.  For example,
Class:BI
> (with the help of loaders like Class:BI::Load
er) produces a flexible
> and relatively standard class hierarchy based on an SQL
schema.  That
> looks pretty similar to the job of someone trying to
create a class
> hierarchy capable of loading data from XML described by
an XML Schema.
> 

Oh for sure, and actually that does help clarify it a bit as
it isn't
dissimilar from dealing with a database schema in some
respects, and
infact Class::XML or something very like it could fit the
bill.

> Your major challenge is the lack of a complete
spec-compliant XML
> Schema processor.  Want to help? 
XML::Validator::Schema is waiting
> for you!

 
Either that or smack abw to fix up XML::Schema of course. 
Do you
have a TODO or something for XML::Validator::Schema? I'm up
to my ears
with all manner of stuff but I can probably squeeze in
extending the
tests or something.  Do you have a CVS of it or is what's
on CPAN
basically what there is?

BTW I get a test failure on yaml.t - I'll send a more
complete triage
separately when I get a minute.

/J\
-- 

This e-mail is sponsored by http://www.integrat
ion-house.com/

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

Jonathan Stowe wrote:
> On Wed, 2006-05-17 at 22:50, Tod Harter wrote:
>   
>> I'm just not sure where a schema adds a lot, given
that perl is pretty
>> close to typeless anyway.
>>
>>     
>
> Sure, but the problem arises where a Perl program or
library needs to
> inter-operate with one written in a strongly typed
language using XML
> messages that are defined in an XML Schema Definition. 
The way I see it
> in this context the best approach might be to fake up
some typedness on
> the part of Perl.
>   
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 
correct. On the outgoing side, where perl is building XML
its pretty 
much the same argument, build valid XML. You can pretty much
guarantee 
well formed XML. It could be useful to build a code
generator that can 
build a writer for a particular object class. A Schema
however can't 
give you all the information needed to do that. It could be
useful for 
determining proper output types, but you still need some
kind of mapping 
information to tell you where in the Schema structure each
attribute is 
going to be mapped.
>   
>> I think the main reason not a lot of tools of this
type exist in perl is 
>> just that most of us don't NEED them all that
badly.
>>     
>
> The reason that I think we do need it is to properly
support WSDL which
> is the formal definition of an interface which is
implemented via XML
> messages which can be (in the document/literal case
that most of the
> major players advocate) defined as XML schema. I'll
leave the discussion
> on why we need Perl to properly support WSDL for the
time being.
>
> /J\
>   

WSDL is highly useful, we use it all the time. Its a bit
different 
situation than a Schema though. In the case of RPC style
SOAP it can be 
useful to be able to build a stub. I'd see that as a
possibility for a 
code generator. Again though, in terms of document/literal
its 
essentially identical to the case of consuming any XML
document, 
validate it. You can certainly generate code to extract data
from the 
document into objects, but again you need mapping
information no schema 
can provide...


I just don't see practically how you can generate much
useful code from 
an XSD schema alone.
_______________________________________________
Perl-XML mailing list
Perl-XMLlistserv.ActiveState.com
To unsubscribe: http:/
/listserv.ActiveState.com/mailman/mysubs

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.

> correct. On the outgoing side, where perl is building
XML its pretty 
> much the same argument, build valid XML. You can pretty
much guarantee 
> well formed XML. It could be useful to build a code
generator that can 
> build a writer for a particular object class. A Schema
however can't 
> give you all the information needed to do that. It
could be useful for 
> determining proper output types, but you still need
some kind of mapping 
> information to tell you where in the Schema structure
each attribute is 
> going to be mapped.
[...]
> WSDL is highly useful, we use it all the time. Its a
bit different 
> situation than a Schema though. In the case of RPC
style SOAP it can be 
> useful to be able to build a stub. I'd see that as a
possibility for a 
> code generator. Again though, in terms of
document/literal its 
> essentially identical to the case of consuming any XML
document, 
> validate it. You can certainly generate code to extract
data from the 
> document into objects, but again you need mapping
information no schema 
> can provide...
> 
> I just don't see practically how you can generate much
useful code from 
> an XSD schema alone.

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

____________________________________________________________
____________

                     James Miller in Austin, Texas
____________________________________________________________
____________

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