RE: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")

["Dare Obasanjo" <dareo@microsoft.com>]

We went back and forth about this sometimes. All input to the XslTransform class can be represented by an instance of IXPathNavigable. However this means that if the user wants to transform input from an XmlReader or a text file, it would take a few more lines of code to first load the XML into an XmlDocument or XPathDocument. Our usability folks counsel that the less lines of codes it takes for the user to perform a distinct task, the better. Secondly, it isn't intuitive to all developers that if you have an XmlReader and a class that takes an IXPathNavigable, how you get from A to B. 
 
There is a similar argument for multiple outputs (TextWriter, XmlWriter, file name, etc). 
 
-- 
PITHY WORDS OF WISDOM
The road to to success is always under construction.   

________________________________

From: Michael Kay [mailto:mike@saxonica.com]
Sent: Thu 2/17/2005 6:53 AM
To: Dare Obasanjo; 'Elliotte Harold'; 'XML Developers List'
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")



Actually, I think the IXPathNavigable interface is an excellent piece of
design, but I think the many overloaded transform methods are horrible.

But of course, this is largely a question of aesthetic judgement and people
can therefore legitimately differ.

Michael Kay

> -----Original Message-----
> From: Dare Obasanjo [mailto:dareo@microsoft.com]
> Sent: 17 February 2005 13:42
> To: Elliotte Harold; XML Developers List
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] What should TrAX look like? (Was: Re:
> [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
>
> >It is, I admit, a hard problem. I suspect it could be solved for
> tree-based models by defining some sort of interface based on
> the XPath
> data model.
> 
> What you've described is akin to the IXPathNavigable
> interface which is the primary input of the XslTransform
> class that Michael Kay was deriding. The other input
> overloads to the method are primarily for usability
> (XmlReader, string, etc) as opposed to being an implication
> that there is some fundamental missing abstraction in the .NET model.
> 
> I'm actually quite disappointed in Michael Kay for (i)
> defending what is obviously a horribly broken interface (i.e.
> Source)and (ii) deriding the .NET model as flawed without
> taking the time out to understand the problems it is trying to solve.
> 
> --
> PITHY WORDS OF WISDOM
> The road to to success is always under construction.  
>
> ________________________________
>
> From: Elliotte Harold [mailto:elharo@metalab.unc.edu]
> Sent: Thu 2/17/2005 3:57 AM
> To: XML Developers List
> Cc: xml-dev@lists.xml.org
> Subject: [xml-dev] What should TrAX look like? (Was: Re:
> [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
>
>
>
> I think we've all implicitly agreed that Source is pretty useless. The
> primary argument in its favor has been a lot of hand waving
> and pointing
> at some .NET thing, and saying, "That's even worse" but
> nobody's really
> stepped up to defend Source on its own merits.
>
> Here's a perhaps more useful question. Could we define an alternate
> source interface that would allow validators, transformers, and query
> tools to hook into arbitrary models? Specifically, could we define one
> that would be complete, unlike Source; and would not require
> these tools
> to provide special support for each different object model? What would
> such an interface look like?
>
> It is, I admit, a hard problem. I suspect it could be solved for
> tree-based models by defining some sort of interface based on
> the XPath
> data model. I am not at all sure it's possible to define this for
> streaming models as well, but perhaps it is.
>
> Possibly the issues of transforms are different from query tools and
> validators. All transform engines I've seen build their own internal
> model. They do not work directly on top of DOM, SAX, XOM, or other
> things. Validators and query tools, by contrast, tend not to construct
> new object models and do work directly on top of the preexisting
> in-memory representations of the XML document.
>
> If that's an accurate characterization (I'm not sure it is) then the
> needs of transforms would be served by a single interface that just
> streamed entire documents into the engine, because the engine is going
> to build a new model anyway. On the other hand, query tools
> might want a
> wrapper around an existing tree model that they could query.
> Validators
> could probably work with either.
>
> I'm not sure it's possible to satisfy all use cases with one or other,
> but maybe it's possible. If not, perhaps we could get away with two
> interfaces instead? e.g. replace SAXSource and DOMSource with
> StreamSource and TreeSource. These would be read-only interfaces that
> would provide full access to what's needed for the XPath data model.
> Each model could implement one interface or the other. Tools could
> support one or the other, but I think most would support
> both. However,
> they would only need to support both. The would not need to specially
> support JDOMTreeSource, XOMTreeSource, DOMTreeSource, SAXStreamSource,
> StAXStreamSource, XNIStreamSource, etc.
>
> Does this seem plausible? Does this seem worth doing? Does anyone have
> any other ideas?
>
> --
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/
> ref=nosim
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>