Rachel was suggesting that the certification program might want to recommend
experimental JEPs, and I'm just trying to explain that this is a bad idea.
Again, even if this has been the mindset in the past, it's not necessarily such now.
I can't imagine the JSF have a certification program involving experimental
JEPs, when you consider the nice red warning text that is currently at the
top of all of them. Left hand, meet right hand?
I think part of the point of all this -- at least over in the jdev chatroom, and in off-channel discussions -- is that the 'oh, experimental, bad don't touch it, it will bring plague upon your project aaaaugh' mindset is itself a bad thing and that maybe that language is a little too strong and too discouraging. It might be better to have something like:
"WARNING: This Standards-Track JEP is currently classified as Experimental, and may be subject to change or replacement in the future; the publication of this JEP does not imply acceptance or approval of this proposal by the Jabber Software Foundation as part of the official Jabber specification. Developers who implement this extension MUST be prepared to change or replace their implementation as the status of this JEP."
Basically... no, you shouldn't implement every experimental JEP. And if you /do/ implement an experimental JEP, you should be prepared that it might still change and thus you might need to change your code; don't go in assuming that the protocol for an experimental JEP is set in stone, but don't assume it's a biohazard you must not touch, either.
In certifications, an Experimental JEP would only be able to be a 'recommended' feature, not a required one, and the majority of features would ideally not be 'experimental' ones anyway, but it would be a way to encourage focus on certain JEPs.
To bring this thread back a little more on topic while still focusing on your issue: a certification level would never /require/ an experimental JEP. That would be silly. But there would be some experimental JEPs which you look at and go, huh, that looks like something we would have be required for this certification level /if/ it were draft... so we'll put it into the 'recommended' feature set. Then authors who are going for that certification can also see a preview of what might well be requirements for the certification the following year; if they choose to start implementing the experimental JEP (and following any changes to it), then if or when the JEP goes to draft status (and thus potentially becomes part of the next certification set), they've already got that feature in place.
I do not think this process would force client authors to adopt new methods of development. If you do not want to implement experimental JEPs, as you apparently do not, you do not have to; no one is going to force you to do so, and no certification level would require experimental JEPs. You could still get a certification without writing the experimental JEPs.
Let's say XHTML-IM (which is Experimental) is a recommendation one year for one particular certification; you do not need to implement it, but you know that it is something which will likely become a requirement once it is draft. If you choose to implement it, yay, you get in ahead of the game, have the structures to support it in place, and you help explore implementation of the JEP. If you do not choose to implement it, there's no penalty. But then let's say XHTML-IM advances to Draft status. So the same certification for the next year now has XHTML-IM as a requirement. Those who did not implement the recommended experimental JEP from the previous year now have to implement it in Draft form; this is no different than your 'wait until its Draft' philosophy. But those who implemented it when it was recommended, rather than required, have XHTML already in their clients, and (presumably) have followed the JEP and accounted for any changes, so voila, they already /have/ that feature which is now a requirement.
Does that help clarify? Or has this become more an issue about experimental JEPs in general rather than specifically experimental JEPs within certifications?
--Rachel
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
