[
Lists Home |
Date Index |
Thread Index
]
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>
>
>
|
