Firstly, even if I'm repeating myself by saying it, it's good to see
active discussion taking place here again. I would like to see that we
can channel the current energy into something of long-term use and value.
Secondly, I think that there's a few things that we need or need to think
about before embarking on spec changes or API specifications:
- Buy-in from more of the CG members -- we've heard from a few
people so far, but doing things properly will require a lot of
email traffic and focus for quite a while, so if people we
haven't heard from have objections or other things they'd like
to see done, now would be a good time to air them
- A copy of the WD -- "We" don't have a copy of the XSL 2.0 WD.
Several of us could lay our hands on the last internal
editor's draft that hasn't been made public, but we, the CG,
don't have a clear-cut right to use it, and nor do we yet have
a CG member-accessible source code repository to keep it in.
Since the XPPL WG is/was a closed group, we would strictly
speaking need Liam or someone within the W3C to make the last
draft public and/or bless our use of it, and we'd need the
infrastructure maintainers to make a Mercurial repository for
us.
- Review of existing requirements -- we should know to what
extent the existing requirements cover what we're talking
about
- A common understanding of the area tree model -- the makeup of
the area tree is described here and there in the text of the
spec. I don't know that there is a comprehensive description
of the area tree that you'd use as the model -- the infoset,
if you like, to deliberately use a loaded term -- for
designing the objects and methods of an API. Several of us
have a mental model of how the area tree fits together, and
some even have one in running code, but we, collectively,
don't know whether we all have the same model in mind, and
we've already had one question today about where the spec says
you should write out the area tree. (IMO, it doesn't say you
have to, but others may disagree.) Having a model of the area
tree would also be useful if and when we get to other XSL 2.0
requirements such as multi-volume indexes.
- Use cases -- another aspect of knowing that we're all talking
about the same thing
Regards,
Tony.