I'm reluctantly adding this to the mix. Reluctantly, because I have no particular itch to see xhtml2 replace xdoc. I was trying (and will try) to help out where I could during this latest effort because that was the focus of FT and I was there, but I don't have interest enough to be a serious contributor to the task in terms of driving it to completion in the way that Thorsten, for example, is doing with views. I guess I'm just wanting to give the disclaimer that I'm really +0 on xhtml2 replacing xdoc in the first place, but contributing my thoughts on what I think a good approach to making it happen might be.
What XHTML2 in core means to me... =================================== When I hear xhtml2 in the core I think of it as simply a replacement for xdoc. Actually, it could live right along side xdoc by using a **.xhtml2 matcher instead of **xml. Introducing a new/replacement source format in the core need not force a change anywhere else in the pipeline no more than we would rethink the pipline for a change in xdoc. We'd be essentially creating a new format to normalize to for input plugins and, for now, we'd be viewing the resultant html of documtent2html as an Interface that we feed and views consume. What are the steps involved? 1) Create an xslt equivalent to document2html.xsl 2) Change the views pipeline to start working off of xhtml2 by pointing the aggregation in **page from **-body.html to **-body.xhtml2. 3) Create a fallback locationmap entry that locates xhtml2 files as the source when the .xml file doesn't exist. 4) Move on to other stuff. Huh? =================================== Wondering where all the views stuff is? the new and improved pipeline? new views terminology?... right?... It's not here because they are different concerns. Much as we decouple and maximize separation of concerns when we program, so too must we decouple major features in a software roadmap -- or at least not unnecessarily couple them. There are several reasons for this generally and specifically to our case. 1. We are an OS project depending upon the itches of voluteers 2. Big, design-up-front stuff is more subject to stagnation, in part, because of #1 3. The views implementation isn't stable. 4. It's easier to work on smaller bits without stepping on each others toes. All of the things being raised recently (views refinement, sitemap refinement, xhtml2 as a source format, xhtml2-based views) under the title "XHTML2 in Core" are largely separate technical challenges that should be addressed separately in my opinion rather than using an internal plugin to redesign all of Forrest. Note that I'm not saying they all shouldn't happen, I'm simply saying that unnecessarily forcing them to be addressed together is not wise in my opinion. They work very nicely in stages: 1) XHTML2 as a source format. 2) Refine views (jx, pojo, etc.) 3) Refine sitemap (maximize lm usage) 4/5) Refine sitemap (improve content addressability [e.g. index.contractname.html] AND bind views to xhtml2. Anyway, I realize this pale's in comparison to Ross' excellent, detailed explanation, but hopefully you get the idea. I'm essentially suggesting that a new internal format need not cause us to question and implement alot of other stuff that will progress in its own good time. Think iterative/evolutionary lifecycle. --tim
