Fwd: Re: [xml-dev] Re: Native XML Interfaces

[Michael Sokolov <msokolov@safaribooksonline.com>]

... re-sending ... went off list by accident ...

On 6/3/13 7:12 AM, Andrew Welch wrote:

>  For example the dev is faced with the challenge of extracting the
>  <title>  and product/@id values from some xml.
>
>  They could:
>
>  - use xquery/xpath
>  - use xom/jdom
>  - use sax/stax
>
>  instead they use a tool to generate an xsd from the xml, then use a
>  binding tool to generate some classes, then use those generated
>  classes.
>
In many programming environments life is greatly simplified when there
is a native object that represents a document: whose properties are
drawn from the document and exposed directly via accessors like getID(),
getTitle(), etc.  While XPath provides a great tool for extracting
property values from an XML dom like jdom,xom,tinytree,etc, I think
there is still some utility in a generic framework for mapping XML to
objects when working in such an environment. I haven't used JAXB and its
ilk directly: in our practice, we ended up creating our own mapper that
relies on annotations and introspection and XPath to do its work.  I
will say this has been a major undertaking, but it is a core part of our
infrastructure, and people seem happy enough to let it do its job. From
a user's perspective it ends up looking like:

class Doc {
...
@XPath("/doc/@id")
public String getId() { return id; }

@XPath("/doc/metadata/title")
public String getTitle() { return title; }

}

for example, and then objects are created using something like:
Mapper.asObject(JDOM, Class)

I don't know if this sort of approach fits into your definition of
things to avoid, but if it does, I wonder how you deal with the problem
of creating "native" objects from XML documents?  Do you just not do
that and try to do all programming in XSLT/XQuery etc?

-Mike