[wsf-dev] wsf-dev Digest, Vol 2, Issue 3: Some Decision Making

[Chad La Joie]

Hey Asa and everyone,
XMLTooling, which our OpenSAML library is built on, is broadly similar 
to things like XML Beans in that it is a tool for unmarshalling data 
from XML into Java/C++ objects and/or marshalling Java object into XML. 
  As Scott mentioned to you, I think where we differ from most other 
projects in our attempt to preserve the DOM as completely as possible. 
In addition there is code for supporting XML encryption and signatures, 
validation, ID attribute and searching support, XML fragment adoption w/ 
proper namespace management, key resolution, and some engines for 
evaluating security tokens (keys and x.509 certs currently) for 
signature processing.

Now, the down sides to XMLTooling are that unlike many other binding 
frameworks there is no code generation tool so you'll find yourself 
writing code that could be generated (we just haven't had the time to do 
this) but in so doing you gain access to a whole lot more areas where 
you can tweak functionality.  Also, since the code isn't ready yet (and 
I didn't expect a lot of people to actually want to use a library this 
low in the stack) there is also no real documentation aside from the 
Javadocs.

While there is currently no official release of XMLTooling yet (we'll 
release it with Shib 2.0 in May) the code itself is pretty stable and 
the vast majority of APIs are set.  So, if you wanted to build on this I 
think you'd be pretty safe in doing so.  Also, having another pair of 
eyes look at the code, offer feedback/suggestions would be great.  As 
far as documentation goes I could devote a few cycles to writing some 
docs for you.

If you have some specific questions or concerns about the library feel 
free to ask.

Asa Hardcastle wrote:
> The predominant notion was that DOM over SAX was the preferred choice  
> for a number of reasons, so, as far as I'm concerned, DOM is the  
> choice we are going with for the moment.
> 
> I'd prefer using Eclipse & ANT, I don't believe there will be  
> anything that is done in the code that will prevent contributers from  
> using their own IDE & build tool.  javac & vi should be completely  
> fine, as I imagine NetBeans, IntelliJ IDEA, and others should be fine  
> - as long as everyone is using subversion properly.
> 
> Does anyone have an objection to Eclipse/ANT?
> 
> The thing that comes to mind that we need to grapple with is what  
> libraries and tools will we use for processing the XML/SOAP. From  
> what I understand OpenSAML has an XML tooling layer that could save  
> us a great deal of time.  Are there any ideas on this?   Scott made  
> it clear that his code keeps the DOM intact (or at least makes it  
> possible to add water and have it back) as well as produces java  
> objects for general consumption.   Scott, where is this in terms of  
> development?  Is it ready to use?
> 
> One of my major concerns is making sure that coders have access at as  
> many levels as possible, from a simple set of factory classes to  
> touching all of the underpinnings.   I also feel that we should limit  
> the number of external libraries that we reference.
> 
> later,
> 
> asa

-- 
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124