On Feb 22, 2005, at 12:56 PM, Aaron Mulder wrote:
Is it possible to validate the "outer" content but not the "inner" content?
no, that is a very large part of my argument against naked xml. Whatever xml technology we use, I don't want it poking around inside my attribute contents. AFAIK the only way to acheive this is with CDATA.
I'm worried about the case where we validate our plan, and the
inner content includes, say, namespaces with HTTP references to schemas,
and we end up trying to validate the inner content, perhaps having trouble
due to slow network connections to wherever the schemas are stored, or
something like that. I'd rather just treat all the "inner" data as an
unrecognizable blob, which is what CDATA provides.
Also, I'm not sure we should always fail if it's invalid -- what if the PropertyEditor (or whatever's going to handle it) is quite forgiving but it looks bad to us?
For instance, suppose the attribute content is a jmx mlet tag -- looks like xml but isn't (no closing tag stuff at the end)
david jencks
Aaron
On Tue, 22 Feb 2005, Dain Sundstrom wrote:
On Feb 22, 2005, at 11:01 AM, David Jencks wrote:On Feb 22, 2005, at 10:38 AM, Dain Sundstrom wrote:On Feb 22, 2005, at 10:27 AM, David Jencks wrote:
I'm not sure this is such a good idea.
It's going to require changing the gbean schema to allow an any element and mixed content in a gbean attribute element. In principle I object strongly to mixed content.
What's the big deal.
mixed content is a disaster.
-100 on any use of mixed content unless the results cannot be achieved
any other way.
I still don't get why.
This is a leaf node (from our view) so if they want to have plain
text or XML that seems fine to me; it is not like html were we would
need to pick our bits out of it. If they actually want mixed content
(xhtml), that would be fine with me also. It seems reasonable to me
to say, this is your slot for your data, put what ever you want in
it.
perhaps in an ideal world, but this is xml, not an ideal world. IMO the xml processing for the gbean deployment should not be looking at what is in an attribute value: the PropertyEditor should be doing that. AFAIK the only way to prevent xml processors of any sort from looking at the "xml" contents is to wrap them in CDATA.
I understand the processor will look for well formed and valid XML, but
I don't see why that prevents us from using mixed context. I mean
XHTML uses this and Xerces can process that. Is there something in our
xml processing code that makes this an impossible feature?
I think the extra complications indicate that the CDATA solution is
much much simpler. Is there a problem with it? What are you trying
to pass in? What are you doing with the results? Do you want an
XmlObject, a string, a DOM element, a STAX stream...?
I believe my original code supported creating a DOM. IIRC, I just
get the content as a string and pass it to the java beans converters.
Unless you use CDATA, the xml processing for the gbean will construct an xml model for the contents. I think this is just plain a really bad idea.
Maybe this is a problem with XMLBeans. Does XMLBeans not support mixed
context?
I want to get a string and pass it to the appropriate PropertyEditor. If it wants a STAX stream, XmlObject, DOM, whatever, it's welcome to build that itself.
I totally agree. But we should be able to have plain old xml in an
attribute and pass that in plain text form to the property editor,
which will reinterpret it as a a DOM, STAX stream, XmlObject or
whatever. We totally agree on this point. The difference is do we
have to wrap this in CDATA, and I feel mixed content is part of the xml
standard (their the ones that named it mixed content) so we should be
able to use it.
-dain
