We should implement javax.xml.transform.Source

[GoogleCodeExporter]

$SUMMARY

GenXDMSource or XDMSource.  We should also potentially implement 
javax.xml.transform.Result, as well.

Note that this is related to issue 70, separating the question of providing 
Source and Result abstractions from the (rather odd) request to introduce these 
javax.xml.transform abstractions into the schema parsing API.

Original issue reported on code.google.com by aale...@gmail.com on 12 Oct 2011 at 5:12

[GoogleCodeExporter]

Mark this 'new'. Silly system assumes that I've accepted it just because I 
opened it. :-(

Original comment by aale...@gmail.com on 12 Oct 2011 at 6:46

• Changed state: New

[GoogleCodeExporter]

Use case for XDMSource or Results is any library that just wants to consume 
GenXDM: it operates on the abstract <N>-s?

Original comment by anli.shu...@gmail.com on 13 Oct 2011 at 9:05

[GoogleCodeExporter]

Errrrrrr.

Well, I recognize the utility of these abstractions, in the context of 
transformation, which accepts and returns Source and Result.

But ... these interfaces are most kindly described as "incomplete".  Compare 
the methods on the implementing classes.  Most Result implementors have a 
getResult(), or getNode(), but getContentHandler() and getLexicalHandler() and 
getXMLStreamWriter() also exist.

Anyone that wants to just operate on abstract <N> should be using GenXDM.  :-)  
Seriously, Source and Result do not provide tree model independence.  What they 
can do, if defined for GenXDM, is provide a reasonable adapter for all 
supported bridges.  I'd suggest that we want constructors for XDMSource that 
look like: XDMSource(N, Model<N>) and XDMSource(N, ProcessingContext<N>) (or 
just the first), and XDMResult().  But how do we supply a useful Result?  
getCursor()? getBookmark()?  We want to return something that provides not only 
the <N>ode, but an abstraction that can operate on it ... or do we just want to 
provide N getN() ?

Original comment by aale...@gmail.com on 13 Oct 2011 at 10:14

[GoogleCodeExporter]

Okay.  XdmResult should have Bookmark<N> getResult() (or getBookmark()).  This 
should mean that:

1) you can pass Source associated with one bridge, Result with another (achieve 
conversion at the same time as transformation)

2) bookmark supplies getModel() and getCursor(). So you get a locked-in-place 
result (the bookmark) and a tool for navigating around (oh, and bookmark 
provide getNode(), too).

Original comment by aale...@gmail.com on 26 Oct 2011 at 8:50

[GoogleCodeExporter]

Ah, another point, from discussions with Anli:

We should also provide a way to convert DomSource to XdmSource, and XdmResult 
to DomResult (for instance).  That is, we should be able to write *our* code 
over GenXDM APIs (for transformation or whatever), but should be able to accept 
existing javax.xml.transform.* implementations, adding an appropriate bridge 
implementation for our internal use, and returning the treemodel-specific trax 
abstraction when we're done.

Original comment by aale...@gmail.com on 26 Oct 2011 at 8:56

[GoogleCodeExporter]

Really not eager to look at this one; even once implemented, we won't see 
utility until some other API decides to support our implementation. These are 
interfaces that are almost the antithesis of interface abstraction.

Original comment by aale...@gmail.com on 26 Jul 2012 at 7:31

• Added labels: Milestone-Future

[GoogleCodeExporter]

This appears to have been done some time ago. It's pointless and stupid, but 
it's done. org.genxdm.transform has both XdmSource and XdmResult, for all the 
good that they're ever going to do anyone.

Original comment by aale...@gmail.com on 26 Sep 2012 at 3:56

• Changed state: Fixed