> > > Malcolm Sparks wrote:
> > > > I disagree strongly. Attributes are a core part of the XML
> > > > specification. Which attributes need to be multiline?
> > >
> > > Specifically the Description tag.
> >
> > Good, so the DTD should specify <description> as an element, not an
> > attribute. Whether *everything* should now become an element, rather
> > than an attribute, just to be "consistent" with the <description> tag
> > is highly debatable... :-)
>
> Debatable indeed, and my opinion is that everything should be elements.
> For consistency. :-)
Ooops, I didn't mean "highly debatable", bad choice of words. It would
not be debatable in a community of XML experts, compare the DTD to any
other publicly available XML DTD and you'll see what I mean.
Read the XML spec. http://www.w3.org/TR/1998/REC-xml-19980210
Attributes are used:
1 To define the set of attributes pertaining to a given element type
2 To establish type constraints for these attributes
3 To provide default values for attributes
2 and 3 provide real value, the importance of which is well understood
by XML practioners.
> > Don't you want to
> > include a well-tested validating XML parser with your editor, rather
> > than write it all yourself?
>
> No, I want to use the validator as all rules are not suitable for a XML
> parser to check.
Which rules exactly? XML can ensure that all bean references to roles,
resource factories, and other EJB homes are properly satisfied within
the same jar. It can ensure that some values are specified, and others
can be left unspecified. It can ensure that I've not misspelled
TX_REKWIRES_NEW, and so on...
Once the parser has done most of the work, I can take over with my
code. All I've got left to do is a few more checks, eg. check the
classes referred to exist in the jar, and check the method tags
properly refer to existing class methods. I'm not advocating that the
validating parser can or should do the whole job, I'm just letting it
do as much as possible, while holding onto the reins.
Also, with a good DTD, I can use a DOM which is easy to navigate. I
might not even need to design or write any data structures to hold the
deployment information in memory. I get so much for free. The current
DTD though spoils the whole experience.
I'm all for using technologies that are the most suitable to get a job
done. Java is one technology, XML is another. Using Java for
everything is using a "golden hammer" to saw a piece of wood.
> > With a better DTD, everyone gets
> > validation for free, using a validating parser (btw, you can get one
> > from Sun - ProjectX), instead of every vendor having to write the same
> > unnecessary code.
>
> As above, a validating parser can't handle the heat. The rules are too
> complex. And every vendor could use the same validator.
With a good DTD, every vendor could use *any* validator. Look no lock-in!
> .. oh.. here
> comes an obvious one:
> REUSE
>
Using XML properly (and the current DTD makes it very awkward to do
so), would open up a whole world of tools, utilities, data stores,
versioned repositories, validators, document editors, object
databases, parsers, viewers and much much more to the humble EJB
deployment descriptor. That's what I call REUSE. I can take an XML
document, apply an XSL stylesheet to it and incorporate it into my
webpage is any way I like. I can put them into a database and query on
them (get me all the beans that have a method with TX_REQUIRED), I can
get all this and much much more with very little coding.
> > And your special EJB editors will be of a higher quality. You don't
> > want that rogue editor to spit out invalid XML that your other tools
> > refuse to read.
>
> If that rogue editor is bad, don't use it. 8-)
<irony>Of course, most software is perfect.</irony>
> This is an important discussion! More comments!!
Sorry to all for repeating the "EJB 1.1 First Thoughts" thread, but I agree
with Rickard, this is important.
Malcolm
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
