Re: Jing validation component (was: JING Transformer...)
Pier Fumagalli wrote: [...] I've made it as generic as possible, and unplugged anything related to Jing back as a schema parser. Still working on it, but look at the interface, and tell me what you think! :-P Cool, that's exactly what we needed and it works like a charm! If you meet Michael Wechner in Amsterdam, tell him to buy you a large beer in the name of the Lenya community :) Thanks a lot, -- Andreas
Jing validation component (was: JING Transformer...)
Pier Fumagalli wrote: [...] It's in Subversion right now... 2.1.x branch, validation block. I tried it, it works nicely - thanks a lot! Unfortunately we need an isolated valdiation service (not a transformer), which I created using your code - mostly using copy paste :( Would you be interested in decoupling the validation functionality (incl. protocol-based entity resolving) from the transformation functionality? -- Andreas
Re: Jing validation component (was: JING Transformer...)
On 6 Sep 2005, at 10:14, Andreas Hartmann wrote:
Pier Fumagalli wrote:
[...]
It's in Subversion right now... 2.1.x branch, validation block.
I tried it, it works nicely - thanks a lot!
Unfortunately we need an isolated valdiation service (not a
transformer),
which I created using your code - mostly using copy paste :(
Would you be interested in decoupling the validation functionality
(incl. protocol-based entity resolving) from the transformation
functionality?
So, a some sort of validation component that can be looked up using
the ServiceManager? Something along the lines of
public interface Validator() {
public static final String ROLE =
org.apache.cocoon.components.validation.Validator;
public XMLConsumer getValidator(String schemaURI);
}
public class JingValidator implements Validator {
...
}
public class JingTransformer extends ServiceableTransformer {
private Validator validator = null;
public void service(ServiceManager manager) {
super.service(manager);
manager.lookup(Validator.ROLE);
}
...
}
Is that what you're thinking of?
Pier
smime.p7s
Description: S/MIME cryptographic signature
Re: Jing validation component (was: JING Transformer...)
Pier Fumagalli wrote:
On 6 Sep 2005, at 10:14, Andreas Hartmann wrote:
Pier Fumagalli wrote:
[...]
It's in Subversion right now... 2.1.x branch, validation block.
I tried it, it works nicely - thanks a lot!
Unfortunately we need an isolated valdiation service (not a
transformer),
which I created using your code - mostly using copy paste :(
Would you be interested in decoupling the validation functionality
(incl. protocol-based entity resolving) from the transformation
functionality?
So, a some sort of validation component that can be looked up using the
ServiceManager? Something along the lines of
public interface Validator() {
public static final String ROLE =
org.apache.cocoon.components.validation.Validator;
public XMLConsumer getValidator(String schemaURI);
What would be the role of the XMLConsumer?
The interface I used looked basically like this:
public interface Validator {
String ROLE = Validator.class.getName();
void validate(String xmlUri, String schemaUri, ErrorHandler handler);
}
But a SAX stream or something else as input would also be fine.
-- Andreas
Re: Jing validation component (was: JING Transformer...)
On 6 Sep 2005, at 13:41, Andreas Hartmann wrote:
Pier Fumagalli wrote:
On 6 Sep 2005, at 10:14, Andreas Hartmann wrote:
Pier Fumagalli wrote:
[...]
It's in Subversion right now... 2.1.x branch, validation block.
I tried it, it works nicely - thanks a lot!
Unfortunately we need an isolated valdiation service (not a
transformer),
which I created using your code - mostly using copy paste :(
Would you be interested in decoupling the validation functionality
(incl. protocol-based entity resolving) from the transformation
functionality?
So, a some sort of validation component that can be looked up
using the ServiceManager? Something along the lines of
public interface Validator() {
public static final String ROLE =
org.apache.cocoon.components.validation.Validator;
public XMLConsumer getValidator(String schemaURI);
What would be the role of the XMLConsumer?
It would be where to send XML events for validation.
The interface I used looked basically like this:
public interface Validator {
String ROLE = Validator.class.getName();
void validate(String xmlUri, String schemaUri, ErrorHandler
handler);
}
But a SAX stream or something else as input would also be fine.
Both should be fine... I'll see if I can hack somehting together.
Pier
smime.p7s
Description: S/MIME cryptographic signature
Re: Jing validation component (was: JING Transformer...)
On 6 Sep 2005, at 10:14, Andreas Hartmann wrote: Pier Fumagalli wrote: [...] It's in Subversion right now... 2.1.x branch, validation block. I tried it, it works nicely - thanks a lot! Unfortunately we need an isolated valdiation service (not a transformer), which I created using your code - mostly using copy paste :( Would you be interested in decoupling the validation functionality (incl. protocol-based entity resolving) from the transformation functionality? Just did a commit to SVN, using the org.apache.cocoon.components.validation package. Can you check out that the Validator interface is what you actually need for your stuff? I've made it as generic as possible, and unplugged anything related to Jing back as a schema parser. Still working on it, but look at the interface, and tell me what you think! :-P Pier smime.p7s Description: S/MIME cryptographic signature
Re: JING Transformer...
Pier Fumagalli wrote: On 1 Sep 2005, at 13:08, Andreas Hartmann wrote: Pier Fumagalli wrote: On 1 Sep 2005, at 08:58, Andreas Hartmann wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). [...] It's in Subversion right now... 2.1.x branch, validation block. OK, I'm updating my SVN. -- Andreas
Re: 2.1.8 (Was: Re: JING Transformer...)
Stefano Mazzocchi wrote: So, here is what I suggest: 1) we attach a label to a 'branch' of a block, not to the block itself. 2) labels should not be 'stable', 'unstable' but 'bugfix' and 'development', or something equivalently neutral in respect of stability which is normally perceived as a measure of how well it remains working in real life rather than how solid its contracts are (not everybody thinks in terms of SoC like we do, especially not their managers and CTOs, anyway). Or we could use the linux style of using odd/even numbers to signify taht without having to find an appropriate name for it. 3) start having two branches for the blocks that require it (cforms is a good candidate), then decide what branch to ship with what version. In fact for most blocks we already have these branches. One contained in 2.1.x and the other one for trunk. So we are already using these scheme and we should make it obvious to everyone. So big +1 Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: JING Transformer...
On 1 Sep 2005, at 08:58, Andreas Hartmann wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). The Lenya community is certainly interested. Does the transformer support protocols for includes? include href=cocoon://schemas/dublincore.rng/ Not the one that _currently_ is in SVN... We desparately need this feature ... Implemented... I just got the first recursive parse from cocoon:// URIs to work... Note, this will ONLY work with JING for now, not with JARV (so, no XSD support, only RNG!) Pier smime.p7s Description: S/MIME cryptographic signature
Re: JING Transformer...
Pier Fumagalli wrote: On 1 Sep 2005, at 08:58, Andreas Hartmann wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). The Lenya community is certainly interested. Does the transformer support protocols for includes? include href=cocoon://schemas/dublincore.rng/ Not the one that _currently_ is in SVN... We desparately need this feature ... Implemented... I just got the first recursive parse from cocoon:// URIs to work... Cool! I'll give it a try as soon as it is available. -- Andreas
Re: JING Transformer...
On 1 Sep 2005, at 13:08, Andreas Hartmann wrote: Pier Fumagalli wrote: On 1 Sep 2005, at 08:58, Andreas Hartmann wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). The Lenya community is certainly interested. Does the transformer support protocols for includes? include href=cocoon://schemas/dublincore.rng/ Not the one that _currently_ is in SVN... We desparately need this feature ... Implemented... I just got the first recursive parse from cocoon:// URIs to work... Cool! I'll give it a try as soon as it is available. It's in Subversion right now... 2.1.x branch, validation block. Pier smime.p7s Description: S/MIME cryptographic signature
Re: JING Transformer...
On 1 Sep 2005, at 13:08, Andreas Hartmann wrote: Implemented... I just got the first recursive parse from cocoon:// URIs to work... Cool! I'll give it a try as soon as it is available. I've added some samples and xmap configuration in the block. Documentation is available in Daisy: http://cocoon.zones.apache.org/daisy/documentation/blocks/ validation.html http://cocoon.zones.apache.org/daisy/documentation/components/ transformers/jingtransformer.html Pier smime.p7s Description: S/MIME cryptographic signature
Re: 2.1.8 (Was: Re: JING Transformer...)
Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? What about the patches in bugzilla ? Will they be applied before 2.1.8 ? Is there a code freeze announced, because I've some work in progress on the FormInstance class in the javaflow block (see [1]), which will result in a patch, too.. regards, tom
Re: 2.1.8 (Was: Re: JING Transformer...)
forgot to copy the link, sorry :-) [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg33424.html Thomas Lutz wrote: Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? What about the patches in bugzilla ? Will they be applied before 2.1.8 ? Is there a code freeze announced, because I've some work in progress on the FormInstance class in the javaflow block (see [1]), which will result in a patch, too.. regards, tom
Re: 2.1.8 (Was: Re: JING Transformer...)
Thomas Lutz wrote: What about the patches in bugzilla ? Will they be applied before 2.1.8 ? Well, some of the bugs on my list have finally percolated up to where my employer wants them fixed so they will be fixed before 2.1.8. Is there a code freeze announced, because I've some work in progress on the FormInstance class in the javaflow block (see [1]), which will result in a patch, too.. There is no code freeze yet. You will see an announcement when that happens. regards, tom Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
On 30 Aug 2005, at 19:06, Vadim Gritsenko wrote: Ralph Goers wrote: Just so you know, if Cocoon Forms is still marked unstable I'll be voting -1. Does it mean Cocoon should go without release for a year? Would you still vote -1 if CForms is not marked stable after 2 years? 3? I don't get it. We should do releases *more* often, not less. I agree wholeheartedly... My personal problem is that we don't release often enough, and in maintaining my system, too many things change from one release to another... 2.1.5 was released 2 years ago now and that's what I use on production. There are non-trivial changes, they do affect a lot the performance/ functionality of my sites, so, for me to switch to current head (or latest release), I need to do a quite extensive test to see if it actually works... So far, what I've done is that internally I forked 2.1.5 and back- porting certain fixes I need, that guarantees me a smooth (and well known) upgrade path... It'd be nice to have a release every month or two, with minimal changes, so that one can easily spot what changes, and if something breaks, identify easily what needs to be fixed... So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be blocked by it at all... Or am I the only one seeing it this way? Pier smime.p7s Description: S/MIME cryptographic signature
Re: 2.1.8 (Was: Re: JING Transformer...)
On 8/31/05, Pier Fumagalli [EMAIL PROTECTED] wrote: On 30 Aug 2005, at 19:06, Vadim Gritsenko wrote: Ralph Goers wrote: snip/ So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be blocked by it at all... Or am I the only one seeing it this way? No: Cocoon is far far more than cforms. cforms is a presentation layer on a system that should be presentation layer independant, so IMO it would not be justifiable in any way to try and couple the release of Cocoon to the stability of cforms. I'd spend the effort to move us to 2.1.8 just to get a look at the new Cocoon stack trace stuff. -- Peter Hunsberger
Re: 2.1.8 (Was: Re: JING Transformer...)
Hi, On 31 Aug 2005, at 12:22, Pier Fumagalli wrote: So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be blocked by it at all... Or am I the only one seeing it this way? I'd agree ... doing a release before the GT and then one after with all the hackathon fixes and changed features makes it easier for people to manage what version they are using. The danger is that there's lots of stuff we want to do and test after the hackathon, and it ends up being next September and we have this same discussion. Mind you, I don't have much time to help with the release, so judge my words accordingly ;-) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: 2.1.8 (Was: Re: JING Transformer...)
Pier Fumagalli wrote: I agree wholeheartedly... My personal problem is that we don't release often enough, and in maintaining my system, too many things change from one release to another... 2.1.5 was released 2 years ago now and that's what I use on production. There are non-trivial changes, they do affect a lot the performance/ functionality of my sites, so, for me to switch to current head (or latest release), I need to do a quite extensive test to see if it actually works... So far, what I've done is that internally I forked 2.1.5 and back- porting certain fixes I need, that guarantees me a smooth (and well known) upgrade path... It'd be nice to have a release every month or two, with minimal changes, so that one can easily spot what changes, and if something breaks, identify easily what needs to be fixed... Actually, I don't disagree with any of the above. I'm all for frequent releases. A quick look shows that the 2.1 branch has had releases on average ever 3.4 months. However, there have only been 2 releases within the last year. We had 4 releases in the first 3 months when 2.1 was delivered. We've had 4 releases since then (about 22 months). So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be blocked by it at all... I don't agree with this though. Sooner or later someone has to say enough is enough already. The issue isn't the frequency of releases. The issue is simply a matter of time. I don't recall how long Woody was in development - I'm sure a lot of you can recall though. However, Woody was renamed Cocoon forms and brought in as the Forms block in 2.1.5 - which was over a year ago. That, by itself, implied some level of stabalization. Since that time from the activity on the user's list it has become obvious to me that CForms is one of the most actively used parts of Cocoon. Now in February it was agreed that CForms would be marked stable in 2.2. However, I don't believe anyone thought that 2.2 would have a release date of mid-2006 or later, which is what we are looking at now. And frankly, I can't wait that long. My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. The fact is that if someone makes changes now that breaks compatibility in CForms, at this point they are probably going to need to be reverted anyway as too many people would be affected. So what I am really saying is that the CForms block is already in a position where it HAS to be considered stable and pretty much has been for quite a while. I simply don't understand the aversion to admitting that. Just mark it stable and be done with it. BTW - I don't have a problem with folks adding new features like Ajax to CForms. From what I can tell it looks like when these things are added great care is being taken not to break anything. Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
Andrew Savory wrote: Hi, On 31 Aug 2005, at 12:22, Pier Fumagalli wrote: So, even if cforms are still unstable, frankly, 2.1.8 shouldn't be blocked by it at all... Or am I the only one seeing it this way? I'd agree ... doing a release before the GT and then one after with all the hackathon fixes and changed features makes it easier for people to manage what version they are using. The danger is that there's lots of stuff we want to do and test after the hackathon, and it ends up being next September and we have this same discussion. I don't recall anyone proposing a release before the GT. But since we are on a cycle where releases are happening about 6 months (or more) apart I cannot afford to wait until next Spring for a stable CForms framework. Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. Just a reminder [1]: All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions. Unless they specifically state otherwise, whatever they post on any mailing list is done *as themselves*. It is the individual point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now, and not even as a director of the ASF. Remember, you are here as a person, as yourself, and not a representative of the organization voicing organization's concerns and desires. You are here to help grow and maintain community as a whole, and community currently needs more often releases much more than a stable cforms block (which is just a bit of software, at the end of the day). Vadim [1] http://www.apache.org/foundation/how-it-works.html#hats
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: Ralph Goers wrote: My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. Just a reminder [1]: All of the ASF including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the ASF, affiliations do not cloud the personal contributions. Unless they specifically state otherwise, whatever they post on any mailing list is done *as themselves*. It is the individual point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now, and not even as a director of the ASF. Remember, you are here as a person, as yourself, and not a representative of the organization voicing organization's concerns and desires. You are here to help grow and maintain community as a whole, and community currently needs more often releases much more than a stable cforms block (which is just a bit of software, at the end of the day). That is absolutely true. I happen to think the community needs both. My opinion is that a community that releases software that it won't stand behind has a significant problem. Vadim [1] http://www.apache.org/foundation/how-it-works.html#hats
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 9:08 AM, Vadim Gritsenko wrote: Ralph Goers wrote: My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. Ralph, your employer is retarded! Sorry, I couldn't help it :-)... [vadim] Remember, you are here as a person, as yourself, and not a representative of the organization voicing organization's concerns and desires. You are here to help grow and maintain community as a whole, Ralph isn't trying to represent his employer in the Cocoon community. He's just saying that speaking just for himself it is a PITA for his job that CForms isn't stable yet, because that prevents him from using it. I don't think Ralph's employer gives a rat's ass about the status of CForms per se... all they care about is that no unstable stuff gets used on their project, and if CForms is unstable that just means he has to use something else (which is a PITA for him, but his company doesn't care). Ralph, is that an accurate portrayal? and community currently needs more often releases much more than a stable cforms block (which is just a bit of software, at the end of the day). +1 to that! Cheers, —ml—
Re: 2.1.8 (Was: Re: JING Transformer...)
On 8/31/05, Ralph Goers [EMAIL PROTECTED] wrote: Vadim Gritsenko wrote: Ralph Goers wrote: That is absolutely true. I happen to think the community needs both. My opinion is that a community that releases software that it won't stand behind has a significant problem. So in that case, take cforms out of Cocoon and make a release, just don't delay the release of the rest of the system. Don't want to do that? Well that's why Cocoon has a well defined way of managing new and/or unstable components. Labelling any components stable before everyone agrees that they are stable could cause more problems in the long run. The fact is, although cforms may be important to you to some of us it makes no difference. -- Peter Hunsberger
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. I think you just mis-interpreted semantics of the 'unstable flag'. See, actual meaning is: unstable: Supported by the community, many people are working on it, expect frequent interface and implementation changes, new features and bugs. stable: Solid code with 3-years-old bugs and patches in bugzilla, nobody is working on it, interface and implementation won't change for foreseeable future. deprecated: stable code which stinks. Once you grog this, you'd get that more often Cocoon releases will lead to greater user community participation, more ideas will float, and active developers move on to other blocks or features (such as OSGi and RealBlocks(tm)) sooner, which will result in abandoning of cforms and marking it as stable... :-P And seriously, I'd argue that your -1 on releases actually *delays* maturity of cforms. Vadim
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: You are here to help grow and maintain community as a whole, and community currently needs more often releases much more than a stable cforms block (which is just a bit of software, at the end of the day). Vadim Vadim, I guess I have to more completely respond to this. If you were to review my posts back to when I first started getting involved with this community you would find that I have always advocated treating Cocoon as a software product, just as websphere, weblogic are. JBoss, Tomcat, the Apache web server, struts and many other open source projects all seem to behave that way. Yet within the Cocoon community there seems to be a resistance to that. And I don't believe that is good for the long term health of Cocoon. While there is an awful lot of creativity here just take a look at our list of blocks. How many are stable vs. unstable? How long will we leave unstable blocks to just sit around? Now I can tolerate this to a large degree with most of these because they don't seem to have a large user base so they don't cause a lot of harm (although they do cause problems in how Cocoon is perceived). I worked for 17 years at a company that produced performance monitoring products for IBM mainframes. We dealt with real customers and their problems all the time. I got very used to putting the company's customers first. What I am doing within this community is a carryover from that. I believe Cocoon's customers - which includes me my employer and everyone else on this list - deserve a stable framework with which they can deliver the products that they create, deploy and sell. I don't believe Cocoon is a play-toy that we can tweek to our hearts content until it is perfect at the expense of our customers. And that is what I see going on here. I have a simple question - if you had to pay for Cocoon and were told that every few months a new release was going to come out but that to upgrade you'd probably have to modify your software to use it, would you buy it or look elsewhere. I know what my answer would be. We already have a hard enough time convincing folks that Cocoon is a great way to build internet applications. We don't need that as well. So while you can argue about frequent releases or whatever, I still want a forms framework that this community is willing to call stable. Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
Mark Lundquist wrote: Ralph isn't trying to represent his employer in the Cocoon community. He's just saying that speaking /just for himself/ it is a PITA for his job that CForms isn't stable yet, because that prevents him from using it. I don't think Ralph's employer gives a rat's ass about the status of CForms /per se/... all they care about is that no unstable stuff gets used on their project, and if CForms is unstable that just means he has to use something else (which is a PITA for him, but his company doesn't care). Ralph, is that an accurate portrayal? Let's not mince words here Mark! Yeah, thanks for rephrasing this. Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. I think you just mis-interpreted semantics of the 'unstable flag'. See, actual meaning is: unstable: Supported by the community, many people are working on it, expect frequent interface and implementation changes, new features and bugs. stable: Solid code with 3-years-old bugs and patches in bugzilla, nobody is working on it, interface and implementation won't change for foreseeable future. deprecated: stable code which stinks. LOL. That is pretty funny! Once you grog this, you'd get that more often Cocoon releases will lead to greater user community participation, more ideas will float, and active developers move on to other blocks or features (such as OSGi and RealBlocks(tm)) sooner, which will result in abandoning of cforms and marking it as stable... :-P And seriously, I'd argue that your -1 on releases actually *delays* maturity of cforms. Actually, I'd disagree. I think it forces attention to a significant community problem. Vadim Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 9:27 AM, Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. Won't stand behind seems like too strong/loaded of a characterization for this CForms thing. Support for CForms has been great. Here's what I think stable means, can somebody please confirm/correct this?: X is stable entails that: (1) Support for X will not be unduly removed, i.e. without going through the deprecation cycle. Support entails that product releases will include X, and that the product will not be released with changes that are known to break X. (2) All future changes to X's APIs will be backward-compatible. Your position is that CForms is good enough, and we should just mark it as stable and have done with it. Because for you, any good enough CForms is better than no CForms, which is what you get as long as it's still unstable, thanks to your employer's bull-headed, inflexible policy. But for my part... I do not want to be stuck with a better than none CForms forever. I want CForms to be right eventually, and I don't want anything closing the door to that. There are still things that need to be done to get it there. And until then, I get to use an almost right CForms, because I don't have anybody telling me what I can and can't use. I certainly do not think that saying we still have more work to do before we promise that there will never be a backwards-incompatible API change constitutes not standing behind our product. Quite the contrary, I think it represents a greater commitment than just close the lid and flush :-/ cheers, —ml—
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: And seriously, I'd argue that your -1 on releases actually *delays* maturity of cforms. Vadim Also, please note that I am not springing this on anybody at the last minute. I believe I first brought up CForms being marked stable in February and then in June. Since noone has even suggested a vote yet I don't believe I'm holding anyone up from anything. I'm simply trying to get this issue resolved. Ralph
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 9:59 AM, Ralph Goers wrote: Since noone has even suggested a vote yet ...because the list of ToDo items for CForms stabilization is a subject of public record: • http://issues.apache.org/bugzilla/showdependencytree.cgi?id=25099 • http://wiki.apache.org/cocoon/22StabilizeCocoonForms cheers, —ml—
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: My employer REQUIRES a stable forms framework, therefore I require a Cocoon release with a stable forms framework. Is your employer (or someone else) ready to pay 2 weeks of work for having a stable CForms? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: 2.1.8 (Was: Re: JING Transformer...)
Mark Lundquist wrote: On Aug 31, 2005, at 9:27 AM, Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. Won't stand behind seems like too strong/loaded of a characterization for this CForms thing. Support for CForms has been great. Yes - you are correct. I didn't mean to imply that the folks working on CForms have not been there to support the user base. I actually consider it one of Cocoon's greatest successes. Here's what I think stable means, can somebody please confirm/correct this?: /X is stable entails that: (1) Support for X will not be unduly removed, i.e. without going through the deprecation cycle. Support entails that product releases will include X, and that the product will not be released with changes that are known to break X. (2) All future changes to X's APIs will be backward-compatible. / We don't guarantee backward-compatibility forever, so 2 is only accurate when taken in the context of number 1. Your position is that CForms is good enough, and we should just mark it as stable and have done with it. Because for you, any good enough CForms is better than no CForms, which is what you get as long as it's still unstable, thanks to your employer's bull-headed, inflexible policy. Well, I wouldn't say CForms is better than none. I'd say it is pretty damn good as it is. I doubt I work for the only inflexible employer in the world. Actually, I might be more inflexible than them, because, as you put it, it is a PITA for me. Also, I am also the one who would have to explain why they cannot simply upgrade from release 2.1.8 to 2.1.9 and it makes me look bad. But for my part... I do not want to be stuck with a better than none CForms forever. I want CForms to be /right/ eventually, and I don't want anything closing the door to that. There are still things that need to be done to get it there. And until then, I get to use an almost right CForms, because I don't have anybody telling me what I can and can't use. Products evolve. Products that don't, die. One should expect that CForms will evolve as well. It is the natural process. However, an unstable block can evolve in unstable ways - or be thrown away entirely. On the other hand, a stable block will evolve in a more controlled environment. We all know this already. I certainly do not think that saying we still have more work to do before we promise that there will never be a backwards-incompatible API change constitutes not standing behind our product. Quite the contrary, I think it represents a greater commitment than just close the lid and flush :-/ By not standing behind I simply mean not caring what impact a change might have on the user base. The point I'm making is I believe we are already to the point where we would not introduce backwards-incompatible changes in CForms without careful consideration. In other words, I believe we are already standing behind CForms but for some reason just don't want to admit it. cheers, —ml— Ralph
Re: JING Transformer...
On 31 Aug 2005, at 03:00, David Crossley wrote:Vadim Gritsenko wrote:My only suggestion; try to extend scope and go for ValidationTransformer, instead of implementing JINGTransformer only.Ok, I tried... I have some code that instead of JING uses JARV, so that if you download the MSV package and dump it in $COCOON_HOME/WEB-INF/lib/ it will automagically discover it and use it no problem.That would be good, but of course we cannot put MSV and friendsin SVN. The creator of that ValidationTransformer held adiscussion here on Cocoon dev [1]. When he found that we couldnot include MSV, he created the wiki page to demonstratewhat he had started.[1] http://marc.theaimsgroup.com/?t=10855751643Problem though, it doesn't work with JING. Actually, JING doesn't work with JARV, as it's throwing an obscure NullPointerException when trying to build a validator from a schema (and I followed the examples to the letter - copyandpaste).It works, on the other hand, with MSV, but we can't have that in CVS...I can put both transformers in SVN, one for JING and one for JARV, note that if you want to use JARV, you _need_ to download MSV (or it's going to fail miserably).Any ideas Pier smime.p7s Description: S/MIME cryptographic signature
Re: 2.1.8 (Was: Re: JING Transformer...)
Vadim Gritsenko wrote: Ralph Goers wrote: My opinion is that a community that releases software that it won't stand behind has a significant problem. I think you just mis-interpreted semantics of the 'unstable flag'. See, actual meaning is: unstable: Supported by the community, many people are working on it, expect frequent interface and implementation changes, new features and bugs. stable: Solid code with 3-years-old bugs and patches in bugzilla, nobody is working on it, interface and implementation won't change for foreseeable future. deprecated: stable code which stinks. Once you grog this, you'd get that more often Cocoon releases will lead to greater user community participation, more ideas will float, and active developers move on to other blocks or features (such as OSGi and RealBlocks(tm)) sooner, which will result in abandoning of cforms and marking it as stable... :-P Then I think Ralph's employer perception could be altered if we modified how we flag blocks and avoid labelling something as 'unstable' when, in fact, several people use it for their commercial offerings and have done so for a while. The first version of cocoon was 1.0 not 0.01alpha as it should have been if I looked at how many lines of code and how much of the planned functionality was there. Perception *is* reality ;-) And seriously, I'd argue that your -1 on releases actually *delays* maturity of cforms. I wholeheartly agree with this, we should release now and set a deadline for the next release as soon as we release one and stick to it unless major showstoppers come up. -- Stefano.
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 10:20 AM, Ralph Goers wrote: The point I'm making is I believe we are already to the point where we would not introduce backwards-incompatible changes in CForms without careful consideration. Indeed. However, that's not the definition of stable that we are working under. Apparently, for us stable means that there won't be any API changes that break backwards-compatibility. I wonder if some compromise approach might work, though. I can imagine a couple, here are my brain-farts: 1) Come up with a new term other than stable to mean guaranteed no future backwards-incompatible API changes, and redefine stable to the meaning suggested by your mail (excerpted above). This of course is to allow unstable to mean the opposite of that, instead of the opposite of what stable means today... :-) Or... 2) Aim for 2.1 stability. The idea is to expedite the stabilization of CForms in 2.1.x, while leaving it unstable in 2.2. (N.B., I am not suggesting breaking synchronization of trunk and BRANCH_2_1_X w.r.t. the forms block... I'm talking only about the block metadata). I dunno, maybe we would even canvas the Cocoon community to find out what features/fixes float to the top of the list. Then, focus in, knock down that short list and pronounce it stable in 2.1.8 or whatever. Meanwhile, CForms is still free to be changed as necessary in 2.2 to get it really right. The rationale is that for users to upgrade from 2.1 to 2.2 is going to entail some changes, block stability notwithstanding. WDY/OT? —ml—
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 10:45 AM, Stefano Mazzocchi wrote: Then I think Ralph's employer perception could be altered if we modified how we flag blocks and avoid labelling something as 'unstable' when, in fact, several people use it for their commercial offerings and have done so for a while. yes, exactly Perception *is* reality ;-) :-) —ml—
Re: 2.1.8 (Was: Re: JING Transformer...)
Ralph Goers wrote: So while you can argue about frequent releases or whatever, I still want a forms framework that this community is willing to call stable. A few things: 1) the simple fact of calling something stable doesn't make it stable, but it *does* in fact alter the perception of those using it. Commercial companies ship software as final when they know it's not. Some distros ship x.0 and people know it's really a beta. We don't do betas anymore because we know people stay away from those and you need the real-life test to find the real bugs. 2) this is open source. you get what you pay for. And, yes, I foresee that companies that will do regression tests on projects that, for one reason or another, fail to do that property or extensively, will make a good living out of that... but their developer's lifes will be miserable and their burn out cycle might kill them before the profit margins start to kick in (not to mention the continuous friction with the community, if they keep those regression tests for themselves). 3) blocks are not properly versioned, because we need real blocks for that. If we had real blocks, we could have two branches: a bugfix one and a development one, just like we do for the trunk, and backport stuff when it makes sense. In this scenario, Ralph will happily use the bugfix branch and Sylvain will happily hack ajax into the development branch and everybody is happy, as CForms have their its own release cycle and version control. 4) software stability is a myth, it's never there, but continue to call something 'unstable' to avoid justifying lack of back compatibility is not a good excuse, not after so many years of being there and being used. So, here is what I suggest: 1) we attach a label to a 'branch' of a block, not to the block itself. 2) labels should not be 'stable', 'unstable' but 'bugfix' and 'development', or something equivalently neutral in respect of stability which is normally perceived as a measure of how well it remains working in real life rather than how solid its contracts are (not everybody thinks in terms of SoC like we do, especially not their managers and CTOs, anyway). Or we could use the linux style of using odd/even numbers to signify taht without having to find an appropriate name for it. 3) start having two branches for the blocks that require it (cforms is a good candidate), then decide what branch to ship with what version. Comments? -- Stefano.
Re: 2.1.8 (Was: Re: JING Transformer...)
On Aug 31, 2005, at 10:58 AM, Stefano Mazzocchi wrote: 3) start having two branches for the blocks that require it (cforms is a good candidate), then decide what branch to ship with what version. Comments? Ship both :-) Seriously: cforms-dev cforms-stable as two separate blocks, spread across all releases (i.e. in each branch). A stable block can only depend on other stable blocks; a dev block can depend on either. ??? —ml—
Re: JING Transformer...
On 31 Aug 2005, at 18:38, Pier Fumagalli wrote: I can put both transformers in SVN, one for JING and one for JARV, note that if you want to use JARV, you _need_ to download MSV (or it's going to fail miserably). Ok, did that, they're now in the 2.1.x branch... Where should I put the documentation? In Daisy already or do we prefer the old site? I've played a little bit with Daisy today, seems funkeee! Pier smime.p7s Description: S/MIME cryptographic signature
JING Transformer...
I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). Is there interest to have it in Subversion? (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Pier smime.p7s Description: S/MIME cryptographic signature
Re: JING Transformer...
On 8/30/05, Pier Fumagalli [EMAIL PROTECTED] wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). Is there interest to have it in Subversion? I, for one, would be very interested. We're doing some complex validation stuff using MSV, Jing would definitely be interesting as well. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: JING Transformer...
Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). http://wiki.apache.org/cocoon/ValidationTransformer It supports JING. It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). Is there interest to have it in Subversion? (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soonish... I guess as soon as Carsten starts VOTE :-) Vadim
Re: JING Transformer...
Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). Is there interest to have it in Subversion? Definitely +1. (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soon :-) Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? I should also be able to commit some time in the second half of September to hopefully close the main remaining points for CForms stabilization. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: JING Transformer...
On 30 Aug 2005, at 17:59, Vadim Gritsenko wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). http://wiki.apache.org/cocoon/ValidationTransformer It supports JING. My 0.02 £ - It's not cacheable (AFAICS) - The source code is a mess - There is no license - The package is fcc.ima (not a domain name) In other words, using that code in a commercial environment is, ehemmm, dubious! :-P Pier smime.p7s Description: S/MIME cryptographic signature
2.1.8 (Was: Re: JING Transformer...)
On 30 Aug 2005, at 18:08, Sylvain Wallez wrote: (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soon :-) Kewl... Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? Could do... I'll start working on HEAD then... I think I have some patches in our 2.1.x local here we never contributed back... I should also be able to commit some time in the second half of September to hopefully close the main remaining points for CForms stabilization. That's brillant! Pier smime.p7s Description: S/MIME cryptographic signature
Re: JING Transformer...
Vadim Gritsenko wrote: (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soonish... I guess as soon as Carsten starts VOTE :-) Vadim Just so you know, if Cocoon Forms is still marked unstable I'll be voting -1. Ralph
Re: JING Transformer...
Pier Fumagalli wrote: On 30 Aug 2005, at 17:59, Vadim Gritsenko wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). http://wiki.apache.org/cocoon/ValidationTransformer It supports JING. My 0.02 £ - It's not cacheable (AFAICS) - The source code is a mess - There is no license - The package is fcc.ima (not a domain name) In other words, using that code in a commercial environment is, ehemmm, dubious! :-P Well, ahem, then make it 'commercial environment'-worthy, and include in svn! :-D My only suggestion; try to extend scope and go for ValidationTransformer, instead of implementing JINGTransformer only. Vadim
Re: JING Transformer...
Sylvain Wallez wrote: (PS: when is 2.1.8 expected? /me is starting a new big-ish project) Soon :-) Seriously, what about right after the GT, once we have squashed a few bugs and patches during the hackathon? I should also be able to commit some time in the second half of September to hopefully close the main remaining points for CForms stabilization. Sylvain That would be awesome and make me tremendously happy! Heck, I'll even buy you a beer at the Hackathon! Ralph
Re: JING Transformer...
Ralph Goers wrote: Just so you know, if Cocoon Forms is still marked unstable I'll be voting -1. Does it mean Cocoon should go without release for a year? Would you still vote -1 if CForms is not marked stable after 2 years? 3? I don't get it. We should do releases *more* often, not less. Vadim
Re: JING Transformer...
Vadim Gritsenko wrote: Ralph Goers wrote: Just so you know, if Cocoon Forms is still marked unstable I'll be voting -1. Does it mean Cocoon should go without release for a year? Would you still vote -1 if CForms is not marked stable after 2 years? 3? Yes. Cocoon without a stable and supported forms framework is a hinderence to its adoption and simply gives people an excuse to run off and use JSF or something besides Cocoon. Also, we have lots of folks using the current implementation. We need to be at the point that we guarantee them that we won't be making incompatible changes at every release. I don't get it. We should do releases *more* often, not less. True. On the 2.1.x branch this means primarily improvement in quality. On trunk it is primarily improvement in functionality/usability. Now we have many blocks on 2.1.x that are marked unstable and it isn't a problem. But when you look at what we consider the cocoon core CForms is ALWAYS included. How can Cocoon be considered stable if one of its core components is unstable? It can't. Vadim Ralph
Re: JING Transformer...
Sylvain Wallez wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). It's cacheable and all that lot... I need to use it with very slightly XML skilled ASP developers moving to Cocoon (and willing to break my entire source tree). Is there interest to have it in Subversion? Definitely +1. Another Definitely +1. I have always been sad that an XML framework did not have ways to easily do validation at any point of the pipeline. -David
Re: JING Transformer...
Vadim Gritsenko wrote: Pier Fumagalli wrote: Vadim Gritsenko wrote: Pier Fumagalli wrote: I'm working on a JING Transformer (using JING in the pipeline to validate a document using RNG). http://wiki.apache.org/cocoon/ValidationTransformer It supports JING. My 0.02 ? - It's not cacheable (AFAICS) - The source code is a mess - There is no license - The package is fcc.ima (not a domain name) In other words, using that code in a commercial environment is, ehemmm, dubious! :-P Well, ahem, then make it 'commercial environment'-worthy, and include in svn! :-D My only suggestion; try to extend scope and go for ValidationTransformer, instead of implementing JINGTransformer only. That would be good, but of course we cannot put MSV and friends in SVN. The creator of that ValidationTransformer held a discussion here on Cocoon dev [1]. When he found that we could not include MSV, he created the wiki page to demonstrate what he had started. [1] http://marc.theaimsgroup.com/?t=10855751643 -David
Re: JING Transformer...
Le 30 août 05, à 18:32, Pier Fumagalli a écrit : ...Is there interest to have it in Subversion? yes, big +1 here. -Bertrand smime.p7s Description: S/MIME cryptographic signature
