Re: Business-Oriented XML

[Jon Stevens]

on 11/16/01 8:58 PM, "Dave Jarvis" <[EMAIL PROTECTED]> wrote:

>   
> 
>   * FROM WIC.FOURNIS
>   WHERE COD_CLIENT=?
>   ORDER BY NOM_FOURNIS
> 
> 
>   
> 
> 
>   

Why the heck would you want to do this anyway? You have to be nuts to write
SQL by hand anymore and why would you want to embed it into your code
anyway?

You guys have totally lost touch with simple concepts like 'MVC'...

Ewww...

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Business-Oriented XML

[Jeff Turner]

On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> Hello, again.
> 
> Neeme Praks wrote:
> > Have you ever had a look at Apache Cocoon project? That achieves all the
> 
> Yes.
> 
> > benefits you outlined in your paper plus more.
> 
> Here are a few items BOX addresses that Cocoon does not (as far as I can
> discern; please correct my errors):
> 
>   o doesn't provide an inherent state-based architecture (it's an aside,
> not focus)

Nope, they threw out the "reactor" (state machine) pattern as being too
hard to manage.

>   o doesn't automatically apply a different view of logic based on the
> domain

Certainly can :) Have a look at Cocoon 2's class
org.apache.cocoon.selection.HostSelector.

>   o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> &connectDatabase)

That's just your particular XSP, which uses an XML entity
"&connectDatabase;" to pull in other XSP. If you put your logic in
logicsheets as intended, then your XSP pages are pure XML.

>   o makes it easy to couple presentation and logic (see below)

Actually, XSP makes it easy to mix *content* and logic (presentation is
in XSLs).

>   o lacks an integrated expression parser
>   o doesn't expose a consistent syntax for doing tasks such as:
>   - file I/O
>   - sending XML to remote servers

Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
equivalent of James Strachan's xtags taglib).

>   - calling native code (Java, C, Perl, etc.)
>   - SQL statements
>   o cookies, FORM parameters, and URL encoded variables are not treated
> uniformly
>   o doesn't use plain XML (i.e., embeds other language source directly)

Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
has a very generic architecture, and I've no doubt that your code could
be integrated as an XSP alternative.


--Jeff

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Business-Oriented XML

[Dave Jarvis]

Hello, again.

Neeme Praks wrote:
> Have you ever had a look at Apache Cocoon project? That achieves all the

Yes.

> benefits you outlined in your paper plus more.

Here are a few items BOX addresses that Cocoon does not (as far as I can
discern; please correct my errors):

o doesn't provide an inherent state-based architecture (it's an aside,
not focus)
o doesn't automatically apply a different view of logic based on the
domain
o extremely complex; it mixes multiple languages and odd syntax (e.g.,
&connectDatabase)
o makes it easy to couple presentation and logic (see below)
o lacks an integrated expression parser
o doesn't expose a consistent syntax for doing tasks such as:
- file I/O
- sending XML to remote servers
- calling native code (Java, C, Perl, etc.)
- SQL statements
o cookies, FORM parameters, and URL encoded variables are not treated
uniformly
o doesn't use plain XML (i.e., embeds other language source directly)

If there's interest, I would be more than happy to illustrate a full
cycle of data acquisition (via HTML FORM) to SQL deposit, retrieval, and
final HTML page.  For those who enjoy gory details, I've made a brief
comparison of Cocoon and BOX for two very simple examples.  The first is
a little counter program, the second shows how to do SQL in both
tongues.

Sincerely,
Dave Jarvis

-=( First Example )=-

 ]] Cocoon's Logic (18 lines of code; tied to Java) [[
 
 
 
 

 http://www.apache.org/1999/XSP/Core";>
 
 static private int counter = 0;

 private synchronized int count() {
 return counter++;
 }
 

 
 I've been requested count() times.
 
 

 ]] Cocoon's XSP (6 lines of generated code) [[
 
 
 
 
 I've been requested 0 times.
 

 ]] Cocoon's XSL (10 lines of code) [[
 
 
 

 
   
 

 
   
 
 

BOX code, in my opinion, is much simpler and straightforward, as there
is no intermediary XSP page:

 ]] BOX's Logic (7 lines of code; tied to XML) [[
 
 
   
 
 
   
 

 ]] BOX's XML (4 lines of generated code) [[
 
 
   0
 

 ]] BOX's XSL (7 lines of code) [[
 
 http://www.w3.org/1999/XSL/Transform";>
 

 
   I've been requested  times.
 

 

By adding "" tags around the English text, you automatically get
a stylesheet that is in the viewer's language (based on their browser's
Accept-Language).  This is part of the architecture; no extra futzing is
required.  BOX makes it difficult to couple logic and presentation.  For
example, to write a "" tag with logic, you must write .  XSL is where the  tag belongs; not snuggled in with
logic.

Let's look at a slightly more complex example, involving SQL.  First
Cocoon, then BOX.

-=( Second Example )=-

]] Cocoon Logic (20 lines of code) [[





http://www.apache.org/1999/XSP/Core";
   xmlns:session="http://www.apache.org/1999/XSP/Session";
   xmlns:request="http://www.apache.org/1999/XSP/Request";
   xmlns:response="http://www.apache.org/1999/XSP/Response";
   xmlns:sql="http://www.apache.org/1999/SQL";
   xmlns:log="http://www.arctis.com/2000/XSP/Log";
   create-session="true">


  try {

&connectDatabase;
FOURNISSEURS
FOURNISSEUR

  SELECT * FROM WIC.FOURNIS
  WHERE COD_CLIENT = ' name="WIC_CLIENT"/>'
  ORDER BY NOM_FOURNIS


  }
  catch (Exception e) {

  }




]] Cocoon XSL (43 lines of code) [[
 
 
 http://www.w3.org/1999/XSL/Transform";
 xmlns="http://www.w3.org/TR/xhtml1/strict";>
 
 

 
   
 

 
   
   
   
   true
   
   
 

 
   
   
 Nom
 Adresse
 Banque
   
   
   
   
 

 
 
   
 
   
   
 
 
 


 

 
 
 

]] BOX Logic (28 lines of code) [[


  



  
* FROM WIC.FOURNIS
WHERE COD_CLIENT=?
ORDER BY NOM_FOURNIS
  
  

  
  



  
  



  
  
  
  
  
  
  
  

  


]] BOX XSL (29 lines of code) [[

http://www.w3.org/1999/XSL/Transform";>




  
  
 Nom
 Adresse
 Banque
  
  
  




  

  
  



  
  

  





-fin-

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standardized jar manifest entries? (Re: How do you version jar files?)

[Peter Donald]

On Sat, 17 Nov 2001 04:02, Craig R. McClanahan wrote:
> On Fri, 16 Nov 2001, Jeff Turner wrote:
> > Java's official versioning spec [1] seems curiously irrelevant. It talks
> > about API specifications, and implementations thereof; not the sort of
> > scenario most people deal with. It's primary use-case seems to be
> > applets (it amuses me how Sun documents can be dated this way;)
>
> I'm not so sure this concept is irrelevant to general purpose application
> development.
>
> * Does your application architecture expose abstractions as
>   interfaces (or abstract classes)?
>
> * Do you have more than one implementation of those abstractions?
>
> * Do the implementations rev independently of (and probably at a faster
>   rate than) the abstractions?
>
> If so, exactly the same versioning model is quite reasonable.

except of course that the spec offers no method to indicate that your 
specification is backwards incompatible with previous versions. That alon 
makes it almost irrelevent.

-- 
Cheers,

Pete


Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standardized jar manifest entries? (Re: How do you version jarfiles?)

[Craig R. McClanahan]

On Fri, 16 Nov 2001, Jeff Turner wrote:

>
> Java's official versioning spec [1] seems curiously irrelevant. It talks
> about API specifications, and implementations thereof; not the sort of
> scenario most people deal with. It's primary use-case seems to be
> applets (it amuses me how Sun documents can be dated this way;)
>

I'm not so sure this concept is irrelevant to general purpose application
development.

* Does your application architecture expose abstractions as
  interfaces (or abstract classes)?

* Do you have more than one implementation of those abstractions?

* Do the implementations rev independently of (and probably at a faster
  rate than) the abstractions?

If so, exactly the same versioning model is quite reasonable.

Craig McClanahan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Standardized jar manifest entries? (Re: How do you version jar files?)

[Danny Angus]

I will, ta, although I'm in danger of getting sucked so deep into Jakarta
stuff that I lose sight of *my job* !

> -Original Message-
> From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 16, 2001 3:31 PM
> To: Jakarta General List
> Subject: Re: Standardized jar manifest entries? (Re: How do you version
> jar files?)
>
>
> You should also have a look at the jjar project in Jakarta
> Commons and also
> the related discussion threads on jakarta-commons on the subject.
> There are
> some common ideas :)
>
> -Vincent


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standardized jar manifest entries? (Re: How do you version jar files?)

[Vincent Massol]

You should also have a look at the jjar project in Jakarta Commons and also
the related discussion threads on jakarta-commons on the subject. There are
some common ideas :)

-Vincent

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Cc: "'Ant Users List'" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 2:01 PM
Subject: RE: Standardized jar manifest entries? (Re: How do you version jar
files?)


> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare
that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
(an
> Ant subproject?) and export the list to the classpath, only one entry for
> each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
>
> > -Original Message-
> > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 12:36 PM
>
>
> 
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries?  Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
> 
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Standardized jar manifest entries? (Re: How do you version jar files?)

[Peter Donald]

Personally I would instead choose to just enhance the jdk1.3 "Optional 
Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something 
better named) and then just add more fixed rules on interpretation of 
versions. The reason is that the "Optional Pacakge" spec is used in servlet, 
ejb and applet containers (and webstart???) atm. It will most likely be 
incorporated into other specs as time goes on. 

It would be much less effort IMO to create a document and magic attribute 
that described meanings exactly rather than adding another cutdown version 
which is not used anywhere outside jakarta.

On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare that
> is .jars and the classpath
>
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
> (an Ant subproject?) and export the list to the classpath, only one entry
> for each package-name, and that the highest version.
>
> Of course that suggests there should be a fourth entry like
>
> Package-stability: alpha | beta | release
>
> so you could a) see this info, and b) decide what version should be used
> based on stability.
>
> d.
>
> > -Original Message-
> > From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 12:36 PM
>
> 
>
> > So how about defining a Jakarta-wide standard subset of jar manifest
> > entries?  Something very simple, eg:
> >
> > Package-name: xalan
> > Package-version: 2.2
> > Package-depends: xerces, 1.4.3
> >
> > Then write a standard Java tool that can query any conforming jar, and
> > print this info. The dependency information would allow the tool to
> > recursively trace down dependencies, and print a complete list.
>
> 
>
> > Does that sound workable? Don't be distracted by talk of taxonomies and
> > classloaders.. those are just applications. All I'm proposing right now
> > is 3 standardized manifest entries, and a tool to read them. That alone,
> > if adopted widely, would be of great benefit in a world of proliferating
> > unidentifiable jars.

-- 
Cheers,

Pete

--
Ancient Go proverb: "Only amateurs 
try to come up with 'fancy' moves"
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Standardized jar manifest entries? (Re: How do you version jar files?)

[Danny Angus]

I like this, a lot, if I had a +1 here I'd use it..
its simple
its addresses a real need
it would facilitate the production of tools to deal with the nightmare that
is .jars and the classpath

Ant could check jars against dependencies, and build the jars from scratch
only if need be.
A new tool could be produced to manage the jar collections on a machine, (an
Ant subproject?) and export the list to the classpath, only one entry for
each package-name, and that the highest version.

Of course that suggests there should be a fourth entry like

Package-stability: alpha | beta | release

so you could a) see this info, and b) decide what version should be used
based on stability.

d.


> -Original Message-
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> Sent: Friday, November 16, 2001 12:36 PM



> So how about defining a Jakarta-wide standard subset of jar manifest
> entries?  Something very simple, eg:
>
> Package-name: xalan
> Package-version: 2.2
> Package-depends: xerces, 1.4.3
>
> Then write a standard Java tool that can query any conforming jar, and
> print this info. The dependency information would allow the tool to
> recursively trace down dependencies, and print a complete list.

> Does that sound workable? Don't be distracted by talk of taxonomies and
> classloaders.. those are just applications. All I'm proposing right now
> is 3 standardized manifest entries, and a tool to read them. That alone,
> if adopted widely, would be of great benefit in a world of proliferating
> unidentifiable jars.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Standardized jar manifest entries? (Re: How do you version jar files?)

[Jeff Turner]

(was getting off-topic for ant-user)

On Fri, Nov 16, 2001 at 09:36:24AM +0100, Markus Kohler wrote:
> Hi, 
> 
> > -Original Message-
> > From: Peter Donald [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, November 16, 2001 12:19 AM
> > To: Ant Users List
> > Subject: Re: How do you version jar files?
> > 
> > 
> > On Fri, 16 Nov 2001 09:47, Conor MacNeill wrote:
> > > Scott,
> > >
> > > There are a number of ways to version jars depending on your taste.
[..]
> > > 4. Add a manifest entry to the jar.

[..]
> 
> If Java would have a standard for this  (I haven't found one) it would
> be really cool to support this with an Ant Task.

Java's official versioning spec [1] seems curiously irrelevant. It talks
about API specifications, and implementations thereof; not the sort of
scenario most people deal with. It's primary use-case seems to be
applets (it amuses me how Sun documents can be dated this way;)

So how about defining a Jakarta-wide standard subset of jar manifest
entries?  Something very simple, eg:

Package-name: xalan
Package-version: 2.2
Package-depends: xerces, 1.4.3

Then write a standard Java tool that can query any conforming jar, and
print this info. The dependency information would allow the tool to
recursively trace down dependencies, and print a complete list.

Btw, note the difference between "Class-Path:" and "Package-depends:".
One specifies physical jar names (a brittle, error-prone solution), and
the other specifies logical, abstract dependencies. This "abstractness"
would allow jar taxonomies to be defined; eg:

Package-depends: jaxp-parser, 1,1

would be satisfied by any JAXP 1.1-compatible parser.

Then one could have an abstract-to-physical-dependency mapping tool, to
translate "xerces, 1.4.3" to wherever you keep your 1.4.3 xerces.jar. An
init script or custom ClassLoader could then make use of this info, so
you'd no longer need 15 xerces.jar files on your harddisk :)

alexandria-dev folks (JvZ, SamR, Geir,..): think of this as proposing a
"guaranteed substratum" of jar metadata, which Gump, JJAR etc can use.


Does that sound workable? Don't be distracted by talk of taxonomies and
classloaders.. those are just applications. All I'm proposing right now
is 3 standardized manifest entries, and a tool to read them. That alone,
if adopted widely, would be of great benefit in a world of proliferating
unidentifiable jars.


--Jeff


[1] http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html

[..]
> 
> Markus

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: BOX: Business-Oriented XML

[Peter Donald]

Hi,

You should read 

http://jakarta.apache.org/site/newproject.html

Essentially your project needs to have a community of developers already 
associated with it and ideally it should have a PMC member who is willing to 
champion the project. While projects can flourish under jakarta it is epected 
that the project would be a success outside of jakarta aswell. 

It doesn't seem like this project satisfies the basic requirements. You may 
want to see if there is any interest in developing it under commons project. 


Another idea would be to make contact with members of Cocoon project at 
xml.apache.org because it seems that in many ways your architecture is 
similar to theirs.

On Fri, 16 Nov 2001 18:39, Dave Jarvis wrote:
> Hello,
>
> Using Tomcat, Xalan, Xerces, and Java-based technologies, I have
> developed a system that completely decouples presentation from business
> logic.  I would like to discuss the system and the possibility of adding
> it to the technologies offered by the Apache Foundation.  Please find a
> brief architectural overview of the system online at the following
> address:
>
>   http://www.joot.com/box/
>
> For a more technical system description, please read the following page:
>
>   http://www.joot.com/dave/writings/articles/bsp/
>
> I look forward to your comments, critiques, and questions.
>
> Sincerely,
> Dave Jarvis

-- 
Cheers,

Pete

--
Which is worse: Ignorance or Apathy? Who knows? Who cares?
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: