Geoff Howard <[EMAIL PROTECTED]> writes:
> Below is the larger picture I envision for a new kind of
> cache invaliditation that I've needed in the past and comes
> up in requests from people using EJB or database driven data
> that is cacheable. I'd love feedback from anyone who's
> interest
I searched the archives but couldn't find any reference to this even
though it seems familiar:
http://jcp.org/en/jsr/detail?id=173
It seems a long time before it will be relevant, but it's certainly
something that Cocoon could exploit. In particular for some kinds of
Transformers and Seri
Matthew Langham <[EMAIL PROTECTED]> writes:
> These discussions resulted in a consortium of 6 European
> companies, whose names are well familiar to the Cocoon
> community, joining forces to accelerate the corporate
> adoption of Cocoon by offering a shared vision of support and
> services. Th
Arje Cahn <[EMAIL PROTECTED]> wrote:
> Another inventory.
>
> 1)
The following came up on xml-dev. It's relevant to the discussions we've
had in the past on SAX parsing alternatives (and somewhat academically
interesting as well :-)
In particular, note the performance comparisons with Xalan...
Peter Hunsberger
-Original Message-
From: Patrick Durus
Richard In Public <[EMAIL PROTECTED]> wrote:
>
> I've been following this thread and also working with
> XMLForm-Flowscript-Hibernate. Apart from that I haven't
> worked with forms for quite a while. In trying to evaluate
> alternative validation techniques it seems that it would be
> helpf
Hunsberger, Peter <[EMAIL PROTECTED]> screwed up and wrote:
> Thinking out loud here: couldn't TextSerializer check if
> startDocument has been called before the first instance of
> character and if not call startDocument? This would make
> things both backward compati
Vadim Gritsenko <[EMAIL PROTECTED]> wrote:
>>
> >> The work around seems to be to wrap the text with pseudo XML eg:
> >>
> >>
> >> Generated text
> >>
> >
> >
> > That is a common requirement for XML parsers.
> >
> >>
> >> But I believe this shouldn't be necessary? Strangely enough
Berin Loritsch <[EMAIL PROTECTED]> wrote:
> >
> > The work around seems to be to wrap the text with pseudo XML eg:
> >
> >
> > Generated text
> >
>
> That is a common requirement for XML parsers.
>
Ok, I'd buy that, except, when I run the transform standalone I don't need
the ha
I've got a large XSLT that dumps out a bunch of stuff for serialization to
text. If I wrap the text with a start and end element and run it through
the XML serializer everything runs fine. If I substitute the text
serializer I get no output. A little bit of debugging shows that the start
documen
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> know what? you really suck at ASCII drawing ;-)
Hah, I just don't have time for it these days...
> Seriously, I don't see the difference between a presentation
> and a view.
Well, in our world, a view tells you things like, I want these 10
Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> Whilst I am in perfect agreement with most of what you said,
> there are a few bits that in my own little heretically
> pervert vision still do not comply.
>
> If, instead, I were able to do content aggregation directly
> on the view, well, then t
Geissel, Adrian <[EMAIL PROTECTED]> wrote:
>
> Just in case someone objects to the mixing of _stylesheet_
> technologies, here's a way to
> wrap a long element set into a table (row/col) structure.
> XSLT is declaritive and recursive - and it helps to be wired
> that way :)
Too bad I hadn
Robert Koberg <[EMAIL PROTECTED]: wrote:
>
> Hmmm... You seem to be making this much more complex than it
> needs to be.
>
> Why not do something like this:
>
> XSL:
>
> CSS:
Many of us have to play well with non-CSS capable browsers...
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> Hunsberger, Peter wrote:
> > Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>if the sitemap is the ultimate pipeline engine and the
> >>flow is the
> >>ultima
> Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > I don't have time to spend on this, but I think what you
> really want
> > is something more like
>
> See? me neither. I don't have time to spend on an *elegant*
> solution for
> my view.
Fair enough, but the solution I wrote t
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> Here is the snipped code I had to write a few days ago in order to
> generate a table of picture thumbnails. Input is something like this
>
whatever
blah
I don't have time to spend on this, but I think what you really want is
somethi
Stefano Mazzocchi <[EMAIL PROTECTED]>
> if the sitemap is the ultimate pipeline engine and the
> flow is the
> ultimate (and transparently statefull!) controller engine,
> what is the
> *ultimate* view, the best template system?
>
> There are a bunch of paradigms on the table but they can b
Bruno Dumon <[EMAIL PROTECTED]>
> On Tue, 2003-04-01 at 20:39, Hunsberger, Peter wrote:
> [...]
> > We're currently doing something like this: we've got a
> metadata model
> > that is mapped using a schema to a XML template that the users can
> > m
Bruno Dumon <[EMAIL PROTECTED]> wrote:
>
> It should be possible to create a form just by describing its
> structure in an XML file (lets call this a "form
> description"). I don't like the fact that for XMLForm/Struts
> the user needs to write a bean just to hold the form data.
We're curren
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> Ugo Cei wrote:
> > Sylvain Wallez wrote:
> >
> >
> > I'm using the flow and I'm using sessions too. The applications I'm
> > currently developing with the flow are composed of many independent
> > "flows", each with its own entry point. Consider
Guido Casper <[EMAIL PROTECTED]> wrote:
> Sent: Thursday, March 13, 2003 10:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: more xmlforms + schematron, why ?
>
>
> I agree, that the lack of support for regular expressions is
> the biggest obstacle to schematron use.
>
> I wonder if anybody is alre
Steven Noels <[EMAIL PROTECTED]> asked:
>
> Before starting to influence Excelon into some direction, I'd like to
> know whether Stylus is in heavy use by the Cocoon community.
> Please get
> back to me if you are using Stylus, and if you have compelling
> Cocoon-related questions/suggestions
Nicola Ken Barozzi <[EMAIL PROTECTED]>
>
> Imagine that we have brought Cocoon componentization to the
> extreme. We could have these layers:
>
> Flow framework| implementation
> ||-|
> Sitemapframework| implementati
Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
>
> Carsten Ziegeler wrote, On 13/03/2003 9.36:
> > The flow stuff is an "optional" component, which means I
> can use it or
> > not. Cocoon started as a web publishing framework and as
> flow is not
> > directly a core component for web publishin
Noticed this on xml-dev today and thought it was somewhat relevant to the
dicussion about sitemap validation. In essence; validate once, run many. If
done this way you wouldn't even need to validate the sitemap each time
Cocoon started up, only if the digest changed...
Peter Hunsberger
-Ori
Ugo Cei <[EMAIL PROTECTED]> wrote:
>
> > (I do have to continue to keep the JDK endorsed directories current
> > with the latest Xerces/Xalan...)
>
> Well, that's probably the reason why you're not having this
> problem ...
>
I wondered about that, but having not explored how the class loadin
Tony Collen <[EMAIL PROTECTED]>
> Likewise, I've seen something like this in code... can't
> remember if it's anywhere in Cocoon:
>
> if ( "something".equals(stringToCompare) {
>...
> }
>
> IMO it seems more straightforward and easier to read if it's:
>
> if ( stringToCompare.equals("somet
Ugo Cei <[EMAIL PROTECTED]> asked:
>
> It looks like they have updated the Xerces parser that is distributed
> with the latest version of Tomcat (4.1.21 beta), and I've
> verified that
> copying the Xerces and Xalan jars from Cocoon to
> $CATALINA_HOME/common/endorsed is not necessary anymore
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> Hunsberger, Peter wrote:
> > Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>What I would love to have, before even touching the flow
> >>_implementation_, is a consistent la
Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
>
> > Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> >
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >
> > Fair enough, but how about a high level sketch of where the other
> > parts fit in? Something like:
> >
> >
Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
>
> > Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >> What I would love to have, before even touching the flow
> >> _implementation_, is a consistent language-unaware
> definition of the
> >> object model that
Pier Fumagalli <[EMAIL PROTECTED]> wrote:
> What I would love to have, before even touching the flow
> _implementation_, is a consistent language-unaware definition
> of the object model that flow scripts will live into, define
> bindings from this object model to JavaScript, so that we all
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>
> Why? well, everybody knows that writing SQL into your code is
> bad since
> it ties you to your database. Adding SQL and javascript is a
> potentially
> incredible RAD tool, but it's potentially horrible down the road,
> requiring huge maint
Jakob Praher <[EMAIL PROTECTED]> wrote:
>
> Am Fre, 2003-02-28 um 17.48 schrieb Hunsberger, Peter:
> > Pier Fumagalli wrote:
> > >
> > > "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Niclas Hedhman wrot
Pier Fumagalli wrote:
>
> "Hunsberger, Peter" <[EMAIL PROTECTED]> wrote:
>
> > Niclas Hedhman wrote:
> >>
> >> I'm playing with the idea of making an attempt at a SAX hardware
> >> accelerator, just for the heck of it, but won&#x
Niclas Hedhman wrote:
>
> I'm playing with the idea of making an attempt at a SAX
> hardware accelerator,
> just for the heck of it, but won't bother if it is already in
> the "ignorable"
> magnitude.
You mean something like:
http://www.datapower.com/products/xa35.html
Of course, it doesn't
Gianugo Rabellino wrote:
> Hunsberger, Peter wrote:
>
> >
> > It seems you've conceptually described the 80% of the
> solution that is
> > easy: the wrapper just has to accumulate each addition in a map or
> > similar. The interesting part (the
Gianugo Rabellino wrote:
>
> Vadim Gritsenko wrote:
> >>> ObjectModelHelper.getResponse(objectModel).addHeader("Vary",
> >>> "User-Agent");
> >>
> >> Not quite what I meant. First, I'm not sure, from the HTTP specs,
> >> that
> >> you can have more than one Vary header, actually I think
> it's
>> Grouping is a standard XSLT problem. It's not real trivial, it
>> usually requires a knowledge of keys, but it's not all that hard
>> either.
>
> True - but in the courses I teach, a lot of students do not get across
> the multi-level grouping hurdle. Could be because of my skills as a
> t
>> > * writing the config file for the GroupingTransformer is less work
>> > than doing the same thing in XSLT.
>>
>> Grouping is a standard XSLT problem. It's not real trivial, it
>> usually requires a knowledge of keys, but it's not all that hard
>> either.
>
> though you'll have to rewrite
>> Bruno Dumon wrote:
>> > Based on some code from the xReporter project, I created a new
>> > transformer for Cocoon that can do grouping and summary calculation
>> > of table-like data (such as the data that comes out of the
>> > SQLTransformer). The grouping to be performed is described in a
> What is a "skin" to you? Some sites need dramatically different XSLT to
produce
> their final result.
A "skin" to me is the ability to swap look and feel within a single
application. Knowing a bit about what you guys do it seems to me that
you've got a different kind of problem (not sure what
>> Given some past history I've had with this, one things seems to be
>> missing: "How to change a vote"...
>
> The text says that a PMC member may vote more than once. Only the last
vote counts.
Cool, that works for me. In other words, if you are changing your vote you
have to explicitly do
> There are definitely situations where you need to have project defined
XSLT.
Possibly so, but "skins" shouldn't be one of them? Just out of interest can
you give a concrete example?
> We use a comination of chroot jails (if shell access) and URIResolvers to
keep the
> dev-user where they shou
> Where the files directory would contain a user's directory which user's
could upload
> there own versions of the stylesheets, ie. skins I would want to define a
specific
> transformer that would not affect the transformations in the rest of the
application
> but would limit the user to using b
> The Vote
> How to Vote
Given some past history I've had with this, one things seems to be missing:
"How to change a vote"...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
In reply to Antonio Gallardo
>>
>> However, the real issue here is how should you be limiting the query?
>> IIRC the LIMIT +1 logic was added fairly recently in order to solve a
>> bug that someone else encountered.
>
> Just for the record, I was the one who find the problem and the solution.
;-)
Just sent a blank reply by mistake, sorry about that.
>> Torsten,
>>
>> You're chasing a non-existent problem. There is never a real life
>> case that will have both good performance for N records and bad
>> performance for
>> N+1 records. The only way you can guarantee having good performance
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 11:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [ESQL] Improvement
On Tuesday 28 January 2003 01:32, Hunsberger, Peter wrote:
> >> if (exist )
> >>LIMIT 5+1
> &g
>>> if (exist )
>>>LIMIT 5+1
>>> else
>>>LIMIT 5
>>>
>> I think this is an elegant solution. What you think?
>>
>> Sure - but the problem is that we also would need to adjust the length
>> of the resultset inside the helper class. (you always want to see only 5
>> rows in your page)
>>
>>> This is the example I tried to explain:
>>>
>>> I have a table that store the status of some tickets. You always know
>>> how
>> many status there can be. > If you said:
>>>
>>> 1-Open
>>> 2-Close
>>> 3-Invalid
>>>
>>> Then if you want to show the history, you will ask for LIMIT 3, but
>>> th
>>
>> There is only one search for which your 5 rows will be at the start of
>> the table. In general, you need an index on the table in order to
>> find your data with any efficiency. If you have an index that matches
>> your search pattern then the search will stop after looking at 6 rows
>
>> if (exist )
>>LIMIT 5+1
>> else
>>LIMIT 5
>>
>> I think this is an elegant solution. What you think?
>
> Sure - but the problem is that we also would need to adjust the length
> of the resultset inside the helper class. (you always want to see only 5
> rows in your page)
>
> The len
> This is the example I tried to explain:
>
> I have a table that store the status of some tickets. You always know how
many status there can be. > If you said:
>
> 1-Open
> 2-Close
> 3-Invalid
>
> Then if you want to show the history, you will ask for LIMIT 3, but the
database will try to find
>>> WHAT IS WRONG?
>>>
>>> In example A all is OK.
>>>
>>> In example B we are not using the power of the Database Manager.
>>>
>>> WHY?
>>>
>>> The LIMIT clause was designed to tell the database engine:
>>>
>>> "Let find just X rows", then the database engine when it got the X
>>> rows stop searc
Timothy,
In spite of what the documentation may say, this works as you expected it to
in 2.0.2 and 2.0.3. I believe it is a bug...
-Original Message-
From: Timothy Larson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 12:15 PM
To: [EMAIL PROTECTED]
Subject: Re: [BUG?] cocoon
Title: Message
We
deploy it as an EAR (WAR plus JAR for EJBs). Nothing to stop you from doing
so...?
-Original Message-From: Steven Punte
[mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 2:38
PMTo: [EMAIL PROTECTED]Subject: Is Export to
J2EE Environment Possible
Stefano Mazzocchi wrote:
> Hunsberger, Peter wrote:
>> Stefano Mazzocchi wrote:
>> I don't think I will! However, when doing architecture you always
>> have to ask if inverting a control flow makes sense; sometimes
>> abstractions suddenly become obvious or
Stefano Mazzocchi wrote:
> Hunsberger, Peter wrote:
>>>>Now, if the "type" was available in the flow, you could get different
>>>>resources for the same flow.
>>>
>>>Well, how would Cocoon know how to match? Say I ask for '/dashboard
Stefano Mazzocchi wrote:
>>>
>>>Oh boy, it's already hard enough to indicate what is a good URI, if we
>>>start discussing what is a 'flow uri' compared to a 'resource uri' we
>>>get in trouble.
>>
>>
>> This comes at the matching issue the opposite way that I did
>> initially: instead of assu
Stefano Mazzocchi wrote: >
Hi again Stefano,
Peter Hunsberger here; I was watching for your reply to this since it seemed
to get specific about some of the issues we had discussed more generally a
couple of weeks ago.
>>
>> So I find the notion of "flow uri's" living side by side with
>> "s
Stefano Mazzocchi wrote:
>> Here the generator reads an Excel document from the input stream that
>> is submitted by the context, and translate it to some xml format. The
>> serializer write its xml input in the file system. I reused the names
>> generator and serializer partly because I didn
>> Whoops, my bad. I guess it was just all the examples I had seen that
>> seemed to refer to a simple named resource and not a URI. However,
>> "send" also seems bad; sort of like "goto" from the evil
>> pre-structured programming days... Also, isn't it possible (though
>> possibly rare) that
>> 3) Punt on distinguishing this behavior with the name of the function.
>> Just add a third (optional) boolean parameter to indicate if it should
>> block
>>
>>sendPage(uri, bizData, waitForInput);
>
> I like the above better.
>
> What I mostly like is the distinction between a 'form' an
> This for me, being able to publish Cocoon based sites by FTP is a bit of a
holy grail.
> For the personal projects I work on, all of which are now based upon
Cocoon, I have
> to use cheap servers that cannot run Java, and thus cannot run Cocoon.
Therefore, FTP
> is the only way.
I can't commen
Stefano Mazzocchi said in reply to Peter Hunsberger (recursively for many
days now...)
>> No problem, I'm somewhat amazed that you have found the time to follow
>> up at all...
>
> Like I said in the past, I like healthy and friendly discussions
> expecially with people that disagrees with my v
>> Andy Lewis wrote:
>>
>>> what about I/O terms?
>>>
>>> sendPageBlocking
>>> sendPageNonBlocking
>>
>>
>> I still like the concept of "waiting" a lot more. In short, your
>> 'server' is waiting for you to come back. It would be like having your
>> personal thread allocated in the server, even
> sorry, it took me a while to get back on this
No problem, I'm somewhat amazed that you have found the time to follow up at
all...
>>>Hmmm, sure. but that is only a very small part of what flow-management
>>>is about. How would you keep the state across requests in XSLT?
>>
>> Same way you woul
>> I'm not sure that this would hit the core? It looks to me more like a
>> resource that wants to call other resources. I plug this new thing
>> into the sitemap, it take over for a transformer at some point, then
>> it calls other resources as defined in the sitemap.
>
> Yeah, that's basical
>> That could be and it's partly why I've started this discussion. This
>> morning in a responses to Ovidiu I pointed out that perhaps what I
>> really want is just to be able to use XSLT as the flow language? I'm
>> not quite sure how that would work, but that's essentially what I'm
>> lookin
>> Let me be clear that I'm not looking for dynamic pipeline generation.
>
> Cool.
>
>> The
>> mapping of URI to generator is well defined for everything that what
>> we want to do. The selection of transformer is a little less so; for
>> example, the 1 result vs. multiple results example we tal
> If you ask me, you should never use the sitemap to describe any
> processing other than page generation.
That is one of our goals and my main rational for looking what ways we can
do that. I think I've stated this several times in this thread, but given
how long it's been going on (and the am
>> >> (Someone has also remarked
>> > that this sounded somewhat like a capability that was in C1.)
>> >
>
>> > yeah, you could implement what you want using dynamically added PI
>> > (processing instructions) for the C1 reactor, but it would
>> end up being
>> > very messy anyway.
>>
>> When it
>> Hmm, I guess I've been exploring this long enough that I thought it
>> was somewhat intuitively obvious, sorry... (Someone has also remarked
> that this sounded somewhat like a capability that was in C1.)
>
> yeah, you could implement what you want using dynamically added PI
> (processing i
Hi Robert,
>> Our users will get their own UI generator which will create an XML
>> description of the UI that they want for any particular "screen".
>> This XML is validated (and constrained by the UI generator tool)
>> against a schema that is essentially assembled dynamically from
>> metad
>>
>> In-other-words: currently, sitemap has access to context via URI,
>> parameters, generators, etc. Based on this, sitemap spits out a
>> decision on what transform to use. What I want instead is to feed an
>> XSLT this same set of context as XML and have the XSLT pick the
>> subsequent t
Hi again...
Well, yes mostly it is, but we have a requirement for very dynamic
business logic and very dynamic flow logic. As a result, I'd like to
keep as much of the logic declarative (specifically, coded in XSLT) as
possible. We really need to mix and match business rules,
Stefano, thanks for taking the time to reply in detail. I'm going to snip
most of the discussion to keep this somewhat terse, but do have a couple of
further comments...
>>
>> Well, yes mostly it is, but we have a requirement for very dynamic
>> business logic and very dynamic flow logic. As
>>
>> I certainly wouldn't expect sitemap to go away, even if the capability
>> I suggest was implemented. In particular, one might want to use both
>> capabilities, directing only some URIs to the router type XSLT that
>> I'm looking at. Depending on how it was implemented one might also
>>
h, h, h, I have FS alarms ringing all over the place in
my head, but I have several great examples of where having that
would rock the planet but still, I'm afraid of people going back
adding programmatical logic to the sitemap
... but it would be
>
>> > At the same time, everybody considered the sitemap one of the core
>> > features of Cocoon and, for sure, this isn't going to go away any time
>> > soon (not even for Cocoon 3.0). this doesn't mean we can't innovate or
>> > propose alternative solutions to cohexist, but for now, I'd concen
>>h, h, h, I have FS alarms ringing all over the place in my
>>head, but I have several great examples of where having that would rock
>>the planet but still, I'm afraid of people going back adding
>>programmatical logic to the sitemap
>>
>>... but it would be *so* cool to hav
> h, h, h, I have FS alarms ringing all over the place in my
> head, but I have several great examples of where having that would rock
> the planet but still, I'm afraid of people going back adding
> programmatical logic to the sitemap
>
> ... but it would be *so* cool to hav
>>And what do you want to do with map:aggregate?
>>
>
> We keep the "cocoon:" protocol for this. But I always have been
> frustrated that map:part only accepts a simple "src", and would love to
> be able to put sitemap statements in it. But that's another story...
Boy, would I like to see this a
> With the caveat that I read the list, but have not worked with many of the
features I read about,
> wouldn't it be posible to create a set of Input Modules to do validation?
I recall a discussion
> about having input modules be able to wrap other input modules, so you
should simply be able to
> a
>> 4. Some users don't want additional protection. They are happy with the
>> current level of (lack of) protection, and add their own as needed.
(Peter
>> Hunsberger)
>
> AFAIU some would also like to have a centralized management...
What I'd really like to see is a good general infrastructure w
> With my limited knowledge of this subject (BTW, I'm not insecure -
> I'm polite) I don't see data checking as the job of the DBMS. DBMS
> simply maintains the data, executes queries that the client provides,
> returns the results and ensures that proper side-effects occur.
> If DBMS executes a ma
> For things like SQL, transformers and the sitemap simple filtering
> should do it. We just need to make sure each individual parameter is ok.
> Everything else is up to the webapp's decision. Plain filtering would
> solve problems where we cannot supply webapp-like logic. Your example is
> defini
>> > As you say - it's crucicial. I think we should force this in any way.
>>
>> I can't think of a one-size-fits-all solution. There are areas where
>> input validation is impossible and unnessary, too.
>
> What areas do you have in mind? I could think of the whole webapp/forms
> area. Anything e
>> String p = request.getParameter("id","id-filter");
>>
>> So filtering would be very easy and as close as possible to the request
>> but not really forced - it would be an option we should document and
>> promote very well.
>>
>> What do guys think?
>
> Torsten,
>
> call me boring, but, wouldn
Many good comments, mostly I think you are actually agreeing with me, so
I'll try and be brief...
>>
>>Yes, and I'm still advocating the brainstorming. What I'm suggesting is
>>that only one person can really "design" something.
>>
>
> I strongly disagree with this : although there must be a
> Since I know I wouldn't have been able to do it alone (Cocoon1 was done
> by myself alone and we saw where that went :), I think it's the entire
> dev community that did the cocoon design.
:-) How many of us can say that any of their first version systems are even
running long after version 2
> So, I came to a conclusion that what Cocoon's documentation lacks is an
> ideological or conceptual papers.
This is also why I've been pushing for someone to take a lead architectural
role. It seems that perhaps Stefano doesn't want to be nominated for the
role, but my motivation seems similar
>> My real point is that I think that it's really hard for
>> multiple people to write an architecture together. I trust that
>> anyone proposing a major change to an architecture is experienced
>> enough or smart enough to know how to get to the end point.
>
> Hmmm, have you ever read some o
>>
>> I've been calling this way of doing software "open development" since
>> "open source" refers to the distribution of software, not the way the
>> development community is run.
>>
>> I don't want anybody (so myself included) to do anything behind the back
>> of anybody. Nor to make it a
>>>Just a note... In Texas Y'all is singular and Y'alls is plural, but
>>>thats only in the Republic of Texas and causes universal confusion
>>>outside of Texas.
>>>
>>>
>>
>>Yes, here in TN the plural is "all y'all"...
>>
>What about you'ns? I've heard that quite a bit in Tennessee, too.
> Just a note... In Texas Y'all is singular and Y'alls is plural, but
> thats only in the Republic of Texas and causes universal confusion
> outside of Texas.
Yes, here in TN the plural is "all y'all"...
-
To unsubscribe, e-m
> I suggest we would need:
>
> 1) a CSSGenerator to convert the CSS to XML as SAX (a wrapper around the
> batik SAC parser).
>
> 2) a CSSCascadeTransformer to "cascade" the styles and apply them to the
> document being styled. This would copy the appropriate style attributes to
> each element of
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103416369316569&w=2
>>
>> shows you voting -1 on this issue If that's not correct, or you'd
like
>> to revoke your vote, then forget the whole issue...
>
> My vote was about breaking existing systems.
> You said that you would put an attri
1 - 100 of 118 matches
Mail list logo
