[jdev] Jabber Certification Program

[Rachel Blackman]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://www.jabber.org/jdev/attachments/20040618/6c9c5f2a/attachment-0002.pgp>