Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: What should TrAX look like? (Was: Re: Article on
 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@m...] > Sent: 17 February 2005 13:42 > To: Elliotte Harold; XML Developers List > Cc: xml-dev@l... > Subject: RE: What should TrAX look like? (Was: Re: > 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@m...] > Sent: Thu 2/17/2005 3:57 AM > To: XML Developers List > Cc: xml-dev@l... > Subject: What should TrAX look like? (Was: Re: > 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@m... > 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> > > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
