Re: Collaborating on EXSLT
Micah Dubinko <[email protected]> Thu, 18 Dec 2008 21:19:08 -0800
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
Thanks, Uche.
I would add that from the start, the wiki should have definite language
about all contributions falling under an agreed-upon license, which
should help avoid some of the nagging questions that have arisen in the
past. -m
Uche Ogbuji wrote:
> As I mentioned in a separate message today, the EXSLT site will be
> migrating to a wiki. I wanted to kick off discussion on how to
> collaborate and how to structure things.
>
> I propose two branches for EXSLT:
>
> * EXSLT 1.x features extensions for XPath and XSLT 1.0
> * EXSLT 2.x features extensions for XPath and XSLT 2.0
>
> The wiki we're setting up is MoinMoin [1], which supports hierarchical
> organization, so we could have:
>
> http://exslt.org - the main page, which includes an overview of EXSLT,
> licensing, links to mailing lists, news, etc.
>
> http://exslt.org/1/ - the main page for EXSLT 1.x, which is mostly a
> list of stable modules
>
> http://exslt.org/2/ - the main page for EXSLT 2.x, which is mostly a
> list of stable modules
>
> http://exslt.org/1/{module-name}/
> http://exslt.org/2/{module-name}/
>
> etc.
>
> There would be a page for each module, with a list of functions and
> element, and a page for each function or element.
>
> I propose separating the spec page for each function or element from the
> list of implementations, reference impl, and so on.
>
> In general once a function or element has been well discussed and
> implemented, it becomes "stable" (I prefer this term to "frozen"), which
> means that changes are only made for obvious errata. Stable extensions
> would be grouped into profiles, which allow us to standardize a complete
> set of extensions. To use EXSLT 1.0 as an example, there might be one
> profile that only defines exsl:node-set, and another that defines all of
> common as well as the sets module. This allows us to more clearly mark
> and certify compliance levels for processors, which right now is a
> complete free-for-all.
>
> In terms of collaborating, most discussion would continue on this list,
> of course, whether stable or in development. There would be a small
> list of editors, folks with write access, chosen largely based on
> positive contribution on the list. The managers would be responsible
> for granting such access. The editors would follow list discussions,
> help establish consensus, and then make any resulting updates. An RSS
> feed of changes to the site would be available, to avoid any surprises.
>
> Does this seem reasonable?
>
>
>