forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: What does "XHTML2 as an internal document format" mean?
Date Fri, 16 Sep 2005 19:22:12 GMT
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

Mime
View raw message