OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Collected Works of SAX

From Len:

> Although, and it may seem inconsistent on my part, if it hasn't 
> got a home, I'm in favor of it going to OASIS based on 
> the policies they use to keep things accessible.  

I think it's probably worth while to separate "home" from
"process".  Last I knew, OASIS didn't offer the level
of services that SourceForge does (CVS, bug tracking
and so forth) ... even this xml-dev list seemed iffy for
quite a while, as I recall.  Such services are essential, and
I seem to recall a phone call with some OASIS VIPs
who said providing them wasn't their goal.

>    They 
> have some good rules about the labeling of such assets 
> that enable them to stay public.   We had to look at this 
> for HumanML and the OASIS rules are as open as it is 
> possible for an org to be. 

I'll accept that for argument:  Given that's so, there's
still no implication that OASIS process/rules need to
be the answer for SAX.  There's been no case made
one way or another, from what I see.

That may be why that notion foundered last time it
came up.  It'd be worth knowing why, before anyone
concludes (by default?) that OASIS is the answer to
all SAX process questions.  (David?)

>      Ask yourself how fast 
> SAX is changing, how and and what breadth of people 
> should have input, what to do when people have to 
> drop out, etc., then look for an org that fits those 
> constraints.   

Historically, xml-dev is that org ... :)

In any case it's a problem of crafting the team that
will handle such issues for SAX -- and what rules
they use.  Similarly, drawing a line around what
parts are SAX (core, and maybe someday library)
versus "collected" bits that may provide fodder for
application libraries (standard or otherwise).

- Dave