gavin.king@gmail.com wrote on 01/08/2009 08:22:37 AM:
> >> However, I'm aware that there are some developers who still prefer to
> >> use XML for everything. I'm not sure exactly how many of them there
> >> are, nor to what extent we should to cater to their needs, nor which
> >> of the XML formats they prefer.
> >
> > Given they already have build tools in place for generating DDs, a
> > syntactical change of this magnitude would require significant rewrites
> > for them to take advantage of this spec.  Adding elements is not as
> > big a deal.
>
> I don't really know what you mean here. I'm not aware of anyone who is
> using tooling to generate metadata relating to dependency injection.
> I'm sure someone, somewhere has done this, but I don't believe it's at
> all common.

While I'm sure it's not "common", there are a large number of ISVs that
do this because they want to build their software to run on more than
one vendor, so they automate the build differences.

There's also a substantial number of enterprise customers that do model
driven development and generate a substantial portion of their code base.

> > I think the point is that you need to know XML Schema with this spec.
> > whereas you follow patterns for the platform DDs.  Assuming you use
> > an IDE and get content assist, most IDE DD editors will preset the
> > DD namespaces so you can get content assist whereas generated XML schemas
> > require knowledge of how to add additional namespaces and configure
> > IDEs to use them.  That's not exactly trivial if all you want to do
> > is develop and use business logic.
>
> My IDE (Eclipse) automagically understands XML schema. There's no
> configuration needed. Yes, I need to add the list of namespaces at the
> top of my file but that's really not very difficult. I'm inclined to
> think that pretty much everyone already knows how to do this. For one
> thing, Spring uses the namespace-based approach, and a big chunk of EE
> developers use Spring.

I understand, but given that distinction, the EE DDs follow the same
pattern and rules and get just as much help from the IDE.  You still
get content assist with documentation, etc.  However, once you start
creating new schemas and they aren't served by an internet location,
you need to start managing your XML Catalog so the schemas for those
new namespaces can be found.

> And the point is that the new-style XML gives you context assist and
> validation for much more stuff than the old-style XML. With the old
> style XML you get content assist for <class> and <method>, elements
> that simply don't exist in the new-style XML! The old-style doesn't
> help you at all when you start typing the actual class and method
> names - which are more or less the *only* things you need to type in
> the new-style XML (where they *can* be autocompleted).

Ok, so what you are attempting to do is turn semantic content into
syntax.  I understand how this can help in some cases, but not all
(e.g. defining method sets), but I think that's beside the point.
The point is that there's a platform pattern.  To integrate with the
platform, I think you need to conform to the platform pattern.  If
you don't like the platform pattern, then the entire pattern ought
to be consistently changed, not just one portion of it.

> > The only caveat to this is that this spec. is supposed to integrate
> > JSF and EJB, so JSF developers are more likely to be familiar with
> > dealing with namespaces.  However, I got the impression that the
> > developers this spec. would be most targetted at would be the business
> > logic developers.
>
> Thanks Jim, this is a point that I had missed: that the approach in
> the current spec *is* already used in the platform, in both JSF and
> JSP ! :-)

Well, to be fair, I don't think the issue is namespaces.  It's the
element / attribute schema style.

> >> Say I'm using a library written by someone else, that can be
> >> configured using a web beans XML schema. How is this schema any
> >> different from any other XML schema that is used by developers today
> >> to configure stuff? Remember, the XML author is not required to know
> >> anything at all about the underlying Java classes and methods to
> >> author this configuration document. They get a schema, and they write
> >> XML using the elements defined by that schema. They don't know that
> >> the element names are actually Java class and method names.
> >
> > A typical component developer doesn't knowingly deal with XML schema
> > unless they are a web services component developer.
>
> I don't believe that's right. All the EE XML formats are defined using
> schemas. Every EE developer today deals with schemas every day.

An average EJB developer that actually updates DDs will use a syntax that
looks like:

<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
<display-name>Testdd</display-name>
<enterprise-beans>
<session>
<ejb-name>cart</ejb-name>
<business-local>test.ShoppingCart</business-local>
<ejb-class>test.ShoppingCartBean</ejb-class>
</session>
</enterprise-beans>
</ejb-jar>

While it's true that this is an XML document instance, most developers
don't know and don't care.  They just follow a pattern for filling out
the data.  That was the point.

> It's certainly true that the vast majority of developers don't
> *define* schemas, but the whole point of this is that they don't need
> to in web beans either: the schema can be generated by javac.

Except for the fact that it IS new schema and they must be aware of
it and the impact on the content.

Anyway, my point remains that platform consistency needs to be maintained
or we will lose the concept of a platform and degenerate into a bunch
of piece parts.  If we can get the platform to move to a more modern
XML style, I'm ok with that too.  I just want integrated consistency.

Thanks,
Jim Knutson
WebSphere J2EE Architect