> > 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.
Agreed. The reason Kohsuke-san liked the Calendar approach is that a
Calendar is aware of the timezone its just come from, a Date is not, its
always GMT. This might be a problem.
Maybe we need a DataTypeHelper class so we can do things like
Date date = DateTypeHelper.getDate( document, "/order/invoiceDate" );
Date date = DateTypeHelper.getDate( element );
Date date = DateTypeHelper.getDate( attribute );
Calendar calendar = DateTypeHelper.getCalendar( document,
"/order/invoiceDate" );
Calendar calendar = DateTypeHelper.getCalendar( element );
Calendar calendar = DateTypeHelper.getCalendar( attribute );
To hide the casts and be decoupled form whether Calendar or Date being used.
The advantage of these helper methods also is that even if the value is a
String (i.e. the document is not XSD aware) then some String -> Date
conversion could take place.
> > 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....
Agreed. Rather like CORBA <-> Java bindings, we need a standard XSD <-> Java
bindings we can all share.
> > 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.
:-)
The only issue with this approach right now for numberic types in XSD is
that Kohsuke-san's current implementation of xsdlib doesn't always return a
Number instance - its sometimes an xsdlib specific object that does not
derive from Number. Hopefully version 2 of xsdlib will fix this shortly.
> > 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)
I've heard of a number of issues with Calendar over the years, I'm not sure
how buggy Date is. At least a Date (or java.sql.Date) can be put in a JDBC
database quite easily. There are issues over accuracy of dates, there could
be a case for a new BigDate implementation for XSD.
> > 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. ;-)
Agreed.
A 'template' is similar to having your own special DocumentFactory that
knows how to make a certain kind of document. I'd like to explore this idea.
For example code generating a DocumentFactory / Document / Element /
Attribute implementations based on some specific template or schema which
could then still appear like an XML document but would internally have a
much more efficient structure in which to store itself.
e.g.
<foo>
<bar>1234.5</bar>
</foo>
The FooElement implementation could contain a single reference to a <bar>
element, rather than a List of content. Similarly <bar> might know it does
not allow attributes and only contains text.
This approach can also strip out unnecessary white space between element
content as well.
> 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.
Sounds a good plan.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-user
