Hi!
Rickard �berg wrote:
> Emmanuel Pirsch wrote:
> This could easily degenerate into a "Yes" "No" "Yes "No" discussion..
You're right, I answer your question then we can let go :-)
> you think they are not both attributes, I do. But just one last example:
> if Reentrant needed to have multiline capabilities, then you'd have no
> option but to make it an element...would then all other attributes as
> you define them also be elements, or should then some attributes be
> elements and some XML-attributes?
I think that simple attributes wich can have valid default values should be
represented as XML
attributes, more complex attributes such as multiline text attributes or objects that
themself have
attributes.
Put in a more simple way, anything that is equivalent to a base type in java and
one-line string
should, IMO, be put as XML attributes.
Note that attribute have more validating power in XML than only elements.
> > XML will covert most of the rules and is a lot more easier to put validation in a
>DTD than in a
> > java program. In a DTD you just have to declare what is valid, in Jva you have to
>write code that
> > must check against specific condition wich take more time and is more likely to
>have bugs.
>
> Funny that you should mention this as the EJB1.1 Public Review
> specification DTD contains *at least* 9 errors. Coding is always coding
> it seems...and these errors probably had to pass an extensive internal
> review process (!)...
That's right, but once the DTD is 'debugged' then you can use it with parser written
in any language
and you can be assured that document that use this DTD are valid without the need to
debug any more
code. (write once run anywhere ;-) ).
> > Maybe if you list some rules than we will not be able to represent in a DTD, this
>would be
> > helpful.
>
> * The text node of Field must be a public variable in the corresponding
> Entity
> * The text node of Ejb-link must refer to a deployed bean in the same
> jar
You're right these kind of validation cannot be done in the DTD. So yes a validator
will be required. I
thonk that the more validation we can put in the DTD to validate the structure of the
XML file the
better it is. Once the structure is validated, we can run a validator to check the
data that need more
validation.
This way, an editor for the DD should not need the class files to perform the
validation required to
produce a XML DD. All it need it's a DTD that can validate the whole structure of the
document.
This mean that the person who must edit the DD need not a the jar files and everything
to produce the
DD. It allow for a better split of responsibility (wich the EJB spec want to address).
The validator should only be run when the bean is actually deployed on a server to be
assured that it
can be deployed without problem.
Also a strong DTD (one with all the required validation for the structure of a
document) will allow one
to use a generic XML editor (like Xeena from Alphaworks) to produce valid XML DD
document.
I think this is the goal of XML.
Why would I need a parser that takes more tham 1 megs to parse a file that I cannot
validate in the
parsing process but I need another piece of code to validate it. And that just to
write a simple text
file wich must respect a specific structure?
I think that if the spec is not to use XML to it's full extent for the DD, then it
should not use it at
all!
--
-----
Emmanuel Pirsch
Sun Certified Java Programmer
Unite for Java! - http://www.javalobby.org/
---
"The intuitive mind is a sacred gift and the rational mind is a faithful servant. We
have created a
society that honors the servant and has forgotten the gift."
- Albert Einstein.
===========================================================================
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".
