(A different way to use java.beans.Introspector ... not using
a predefined DTD to ensure validatability ...)
> I think the most important goal of bidirectional Java/XML
> interop is in going *from* XML *to* Java, not the other
> way around.
But then where would the XML content come from? I don't think
you can solve one problem without the other. If one assumes Java,
then DCD tagging isn't needed:
<com.example.foo.SimpleBean>
<prop1>49</prop1>
<prop2>hello world</prop1>
</com.sun.example.foo.SimpleBean>
since all the type info is in the class for SimpleBean! Not
particularly validatable unless you generate a DTD from the
class file, which may be an issue. (I'm assuming there that
most Java names are legal XML names, but there are surely
some exceptions.)
> As such, asking document authors
> to follow a Bean-specific DTD isn't such a good idea. Network
> effects are your friend! 8-)
The question was originally about serialization, so I was
assuming that such documents wouldn't generally be written
by a document author so much as by a tool of some kind.
Also, which particular network effects to leverage? ;-)
One more comment: I really see "serialization" approaches
as being in a different direction than document based ones.
That is, if I'm working with an OBI/OTP/OFX DTD for some
sort of E-Commerce system, the external format is defined
already. There are elements in the DTD that won't match
the model of a property. If we associate elements with
beans in at least some cases, they'll need to be able to
choose which elements correspond to properties. Also, they
need to arrange "appropriate" handling for non-property
elements (whatever that may be).
- Dave