On Tue, May 25, 1999 at 02:27:27PM +0200, Rickard �berg wrote:
> Hi!
>
> 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... :-)
> > Consistency is achieved through effective DTD based validation, the
> > current DTD encourages document inconsistency. One of the best things
> > about XML is that you can define the DTD so that the parser does much
> > of the validation work for you. Describing validation in comments in
> > the DTD suffers from ambiguity and requires each vendor to write new,
> > potentially buggy code to do validation that could be done, for free,
> > by well-tested parsers.
>
> But since a validator will be released from JavaSoft, wont that solve
> the "requires each vendor to write.." issue?
No. A "validator" could mean a command line tool to check DTD
validity. Who knows? But Rickard, don't you want your container/server
to check the validity of EJB assembly as it is loaded, rather than
relying on the developer to have used Sun's tool? Don't you want to
include a well-tested validating XML parser with your editor, rather
than write it all yourself? 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.
> > Another example, is XML linking. The current EJB DTD forces each
> > vendor to ensure that links are completely specified, for example,
> > between EJBs and datasources, ie. not dangling. By using the standard
> > ID and IDREF attributes, the XML parser would be able to ensure this
> > without the need for more container logic.
>
> Right on!
>
> > > I don't see this as a problem as editors will be used to edit the XML
> > > files, and there will be validators available which cover all nasty
> > > rules.
> >
> > This IS a problem. Another good thing about XML is that it can be read
> > and edited without special software. In any case, a good DTD will make
> > it easier to write these tools, enhance portability of deployment
> > descriptors, and improve overall quality.
>
> Agree, sort of. It will be more convenient to use editors, but granted
> sometimes Notepad is unbeatable ;-)
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.
> > My main point is that the spec. should try to make bean portability as
> > viable as possible. We all respect standards, otherwise we wouldn't be
> > on this list in the first place! My suggestion is that years of
> > experience in good DTD design from other parts of the industry should
> > be utilised before the spec. is finalised.
>
> Well, at least when the typos and errors have been smashed out of the
> current DTD+example it will probably be fine.
Well, my point is that even if the typos and errors were fixed, it
would still not be fine. :-) I am only complaining because I think the
current situation means a great opportunity to enhance EJB
portability has been missed. :-( The only chapters that reference the
DTD are 11.4, 14 and 15. Improvements to the DTD could be made with
little effect on the rest of the spec.
Any thoughts anyone?
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".
