Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <b8564462b6955e6df8d63c8df75f1098@yahoo.com>
References: <421B3435.4010307@toolazydogs.com>
 <51c529f23642b3111a8427f6201392c1@gluecode.com>
 <c04407f97cbe5e5daab7a459fc08a004@yahoo.com>
 <5fcbd71eaf6028b8879020aa45e84ad3@gluecode.com>
 <b8564462b6955e6df8d63c8df75f1098@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <cd4300dd74201070dd4d3f963c9e8e40@gluecode.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dsundstrom@gluecode.com>
Subject: Re: CDATA and GBean attributes
Date: Tue, 22 Feb 2005 12:14:50 -0800
To: dev@geronimo.apache.org

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