Hi Toby,
> which currently has a few limitations. Kohsuke Kawaguchi is the author at
> Sun and he's been very helpful during development and hopefully these
> issues
> will be resolved soon.
Fine.
>
> There are currently a couple of issues over what standard Java objects
> should map to which XML Schema Data Types. For example, should a
> java.util.Calendar be returned for all date related fields? What about
> gYear
> / gMonth and gDuration and so on.
That's really a problem. But that's also a problem if you try to map it to
Database Types.
DATE is ok, but how to store gYear ?!? so that it is is in right format in
_every_ database.
>
> We're trying to get the JAXB and JAXM crowd together with the XSDLib
> people
> to find out what the standard mappings should be. Once thats sorted out
> hopefully version 2 of the XSDLib will come out which will solve many of
> the
> current problems with XML Schema Data Type support.
I appricate that they are eager to find a common solution. ;-) Avoids
Generic workarounds....
>
> What I want to be able to do is code things like:-
>
> Number n = document.numberValueOf( "/order/amount" );
> Number n = (Number) attribute.getData();
> Number n = (Number) element.getData();
>
> for all numerical types in an XML Schema document then different Number
> implementations (Byte, Short, Integer, Long, BigDecimal, BigInteger and
> others) could all be returned.
That would be *quite* cool.
> Probably for all dates and durations, Calendar will be the most applicable
> since its timezone aware and works better with days of the month or months
> of the year duractions. So a date like code would be
Yes. But keep in mind that Calendar and Date are very still buggy. ;0)
>
> Element element = (Element) document.selectSingleNode(
> "/order/invoiceDate" );
> Calendar calendar = (Calendar) element.getData();
> Date invoiceDate = calendar.getTime();
What I would like to have in dom4j is a template mechanism. You start to
parse a schema.
Then you create an empty document based on the schema (the "template").
Would be an elegant solution for a always repeating task. I currently use XSLT
for that job, but I think with dom4j Schema API we can make a reusable
approach. ;-)
What I currently do is table-driven mapping. So I had to convert the schema
into a DDL file. That problem on this task is - and I that's the reason why I
guess XSLT is inconvient - had to store the output in reverse order (not
sequential as XSLT normally does).
I think I can find a weired XSLT algortihm that does this, but a dom4j
approach would be much better. I will implement such one if the xsd-lib
understands namespace xsd for her types.
thx
-toby
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
GMX Tipp:
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
