kxml_compiler

[Frans Englich]

On Tuesday 31 January 2006 19:59, Allen Winter wrote:
> On Tuesday 31 January 2006 14:50, Allen Winter wrote:
> > Howdy,
> >
> > I was wondering if kxml_compiler (which is currently located in
> > kdepim/kode/kxml_compiler) should be moved into kdelibs4.  It seems like
> > a general purpose tool that is not pim specific.
> >
> > Also, kxml_compiler doesn't generate correct code for the
> > kdepim/kresources/featureplan. I am working on fixing the problems there,
> > but that is a separate issue.
>
> I suppose I'm really asking if we can move all of kdepim/kode into kdelibs.
> This gives us the kxml_compiler and the kwsdl_compiler in kdelibs.

I think it would be useful for readers(including me) if these questions were 
answered:

* What is kxml_compiler?
* What is kwsdl_compiler?

I wonder about the justification for kdelibs inclusion. The "two or more usage 
scenarios must exist"-rule which often is applied could perhaps be answered 
here as well. What needs k{xml,wsdl}_compiler except kdepim?

Another issue, is that I think there are known bugs in this code. For example, 
KWSDL uses Qt's QDate/Time classes for handling W3C XML Schema(WXS), and they 
simply are insufficient for that. QDate's range is incompatible, and the 
lexical representations WXS uses are not compatible with Qt's classes(it's 
not ISO8601). Primitive types are also missing(gYear, durations, for 
example); some seem wrong("binary" doesn't exist, perhaps hexBinary was 
intended? typemap.cpp:80); xs:boolean seems to be handled wrong; I need to 
look more closely in order to say something definite.

While my comments should be taken lightly considering my low insight in the 
code, I preliminary say that kwsdl assumingly works for the cases in kdepim, 
but has conformance problems with arbitrary schemata. I think code in kdelibs 
should have a wholeness over it. That is, in the case of KWSDL, accept WXS 
primitive types since that is its intent(AFAICT).

KDOM's growing XPath 2.0/XQuery 1.0 implementation KXPath, has a rather 
complete WXS Part 2 implementation. This is code whose idea is to end up in 
kdelibs, so perhaps 1) that it could be used in KWSDL if it's an improvement; 
and 2) That we pretty much have an upcoming code duplication in kdelibs as it 
is now. I've mailed with Tobias Koenig about this in private, but that thread 
died. 

Clearly, I would like to see code merging in that area, but I see a problem: 
KDOM is not in kdelibs, it's in kdenonbeta. Perhaps possible approaches are 
to:

A: Queue kxml/kwsdl inclusion until KDOM's future is known. That is, 
discussing KDOM inclusion is started on khtml-devel, and after that 
kxml/kwsdl can continue.

B: One doesn't put KDOM into the picture and take future problems as they 
come, no matter how likely they are. (that is, if kwsdl/kxml is decided for 
inclusion at all)

I also have more low level comments on KWSDL/KXML, but why not get the broad 
scope clear first.


Cheers,

		Frans