On Tue, 19 Jun 2001, James Strachan wrote:
> From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> > On Mon, 18 Jun 2001, James Strachan wrote:
> >
> > > > I think I'd prefer having XSLT operations inside a different package
> than
> > > > XPATH operations. XPATH isn't part of JAXP, so your XPATH
> > > > support introduces additional dependancies that aren't strictly
> necessary
> > > > for transformations (e.g. dom4j). My preference would be to work on
> > > > seperate tag libraries that complement one another. Is there anything
> in
> > > > your tag library that would prevent this approach?
> > >
> > > Yes. I want to be able to combine XPath and XSLT operations together-
> such
> > > as to style a fragment of a document - so the XSLT tags in XTags are
> > > dependent on the XPath engine (dom4j right now).
> >
> > Guess I don't follow here. You're using JAXP to do your transformations,
> > right? So any transformation you're doing inside your current taglib, it
> > should be possible to do in another taglib. I'd be OK with
> > building support for DOM, dom4j, etc. objects into the XSL taglib, if
> > that's what it takes. Perhaps we can do some creative organization of the
> > classes to avoid runtime dependencies.
>
> I don't think I explained myself very well. JAXP does the transformation,
> the difference is where the XML and XSL come from.
>
> The <xtags:style> tag is dependent on both DOM and dom4j as the XPath tags
> can be used to select a fragment of a document to be styled via XSLT or the
> tag can take dom4j or DOM objects as the source (or stylesheet) to be styled
> via JAXP.
All that sounds like useful functionality for the basic XSL tags as
well. That's why I want to avoid two sets of classes. (XTags does this
but not that, XSL does that but not this.)
> e.g. following example uses both XPath and XSLT on the same document
> instance...
>
> <xtags:parse url="http://www.something.com/book.xml"/>
>
> title <xtags:valueOf select="/book/title"/>
>
> <xtags:forEach select="/book/overview">
> <%-- only use XSLT if we've an overview --%>
> <xtags:style xsl="overviewAsHtml.xsl"/>
> </xtags:forEach>
>
> <xtags:forEach select="/book/author">
> authored by <xtags:valueOf select="name"/>
> </xtags:forEach>
>
>
> So the <xtags:style> tag has both compile time and runtime dependencies on
> both the DOM interfaces and the dom4j interfaces.
I don't think I have a problem with adding that to XSL, if that's what it
takes to bring the implementations together.
> If this isn't a problem we could share the same code across both XTags and
> XSL - it could be the same library just with 2 TLDs or something.
Sure, that's what I think is best.
> We could try refactor most of the code from <xtags:style> and <xtags:param>
> tags (and the backwards compatable <xtags:xalanStyle> tag for use in JAXP1.0
> containers) into XSL without the DOM or dom4j dependencies, then XTags could
> derive from the XSL implementations.
>
> Though I'm not sure its worth it. The support for XPath has made the
> implementation logic quite different I suspect (e.g. the logic of
> doStartTag() and doEndTag() are quite different in the XTags version to what
> I remember of the XSL version). So it could be more trouble than its worth
> reusing. Calling a transformation with JAXP is mostly glue code anyway so in
> this case I'd prefer an easy life than resusing 20-50 lines of code. (e.g. I
> can imagine the <xtags:style> tag getting quite brittle if it derived from
> the <xsl:style> tag and someone changes <xsl:style>).
I'd like to peek at it and see if it's possible to remove non-JAXP
dependencies at runtime (don't care about compile-time); other project
have managed similar tricks. But if it's prohibitive, I'm willing to
increase the XSL dependencies in order to remove the duplication of
effort.
> >
> > >
> > > > Some of the XTags
> > > > features you mention are also present in XSL rel2, and the others
> could be
> > > > merged in
> > >
> > > Due to the XPath dependencies (e.g. dom4j) its probably best if we keep
> > > these 2 libraries seperate for now.
> > >
> > > XSL rel2 for just JAXP based XSLT
> > >
> > > XTags for XSLT + XPath and the rest (<xtags:forEach>, <xtags:valueOf>
> > > <xtags:choose> / <xtags:when> /<xtags:otherwise> and so on).
> >
> > I'm OK with that, if we can finagle it so that your XSLT logic is
> > literally driven by the classes in the XSL tags. I think it's overkill to
> > have competing implementations within the same project.
> >
> > If we note on the XSL page that the classes are also included in XTags,
> > then both projects benefit, I would think. Maybe I should experiment a
> > little with that. Creating larger tag libraries from slices of more
> > focused tag libraries is an appealing concept to me.
>
> Agreed. Certainly aligning the tag libraries would make sense I think and
> from a documentation perspective both libraries should cross reference each
> other. We could try agree on the semantics of the tags so they look and feel
> the same, even if the implementation differs somewhat. From an
> implementation perspective it will probably be much easier to keep them
> seperate though I think.
>
> >> > I'd prefer to just have one tag library for working with XML which
> included
> > > XPath and XSLT really but I agree that some may wish to only depend on
> JAXP.
> > >
> > I could be talked into that, as long as they're using overlapping
> > code. Otherwise, I would rather drop support for the XSL taglib. You're
> > tags are more mature than rel1, and rel2 is just on a branch and therefore
> > relatively hidden from the users for now.
>
> One day maybe JAXP might fully support XPath so this might not be much of an
> issue. Until then keeping both libraries and aligning them closely would
> make sense I think.
>
> For sure rel1 should be replaced by rel2 then we could try aligning the XSLT
> tags so they behave the same?
>
I'm still inclined to not release rel2 if we can't bring the
XSL implementations together; deprecation is a better option. If we can
bring them together, then great; if not, I don't really want
to be working on the same classes as you. Seems wasteful. I'd rather
have two guys working on one lib then two guys working on two. :(
This reminds me of when Jakarta released ORO. There was not a lot of info
on what the advantages/disadvantages were between ORO and Regexp, and it
just left me cold as a user. I'd like to avoid that here if possible,
even if that means shelving a new XSL release.
- Morgan
