Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of eliast@gmail.com designates
 64.233.184.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Y+k1NSvq8wAR+HsoHMKr2p24Ex2cjhMVgVnzO7M+QDqf8dbMhzQZit6oytq/dsN7Wn1LSfgUH0pf7j2iKFdhslsyNTOEtUvYTIEXZtO/CjG/cmWAG9YcmLAqo4QY4+5QXBrfFCyJutDL/pRpuiGl/QBVdq/2jST3aUuiP1QA0b0=
Message-ID: <905f7c910606281829s18ca8dch7d8bd044f86b68d5@mail.gmail.com>
Date: Wed, 28 Jun 2006 21:29:39 -0400
From: "Elias Torres" <elias@torrez.us>
Sender: eliast@gmail.com
To: abdera-dev@incubator.apache.org
Subject: Re: svn commit: r417652 - in
 /incubator/abdera/java/trunk/parser/src/main/java/org/apache/abdera/parser/stax:
 FOMContent.java FOMDiv.java
In-Reply-To: <44A2721A.2000103@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060628030804.777DF1A983A@eris.apache.org>
	 <44A1FF85.1010800@torrez.us> <44A2721A.2000103@gmail.com>

Cool.

On 6/28/06, James M Snell <jasnell@gmail.com> wrote:
> Elias,
>
> One of the reasons I did this the way I did was that it isolated the
> change to just a couple of methods and is easy to roll back if need be.
>  There are already a number of issues with this change that we'll need
> to resolve.  First of all is what happens if the div happens to contain
> xml:base and xml:lang, since we're not automatically pushing those
> things down to child elements, dropping the div silently ends up causing
> significant data loss.  Obviously, that's a bad thing.
>
> What I think will be a better approach would be to roll back this change
> and set a separate API on either the Content or Div interfaces for
> returning the unwrapped content (e.g. getUnwrappedValue or something).
> That method would be required to automatically push xml:base and
> xml:lang down to the child elements of the div.
>
> - James
>
> Elias Torres wrote:
> > I really appreciate that James is very open to suggestions and reacts
> > quickly to people's comments, but I think we need to work more on the
> > voting process/discussion of changes before we commit them.
> >
> > Let me tell you my needs and hopefully we can see why we need to think
> > about this change a bit more.
> >
> > I'm working on converting Atom to RDF. This work is mostly about
> > defining a data model for Atom not just another representation format.
> > It was very enlightening to learn about the extra div element in the
> > spec, because it allows us to shove xml:base and xml:lang into it
> > without having to touch the actual content of the entry. Therefore, a
> > setContent that automatically adds the wrapper div actually doesn't work
> > for me, because I need to be able to manipulate the div before setting
> > it. It might be the case that there are work-arounds or my problem is a
> > non-issue, but in general I think we need to have more discussion around
> > our implementation changes and votes  before making fundamental changes
> > like this one.
> >
> > Just my 2 cents.
> >
> > -Elias
> >
> > jmsnell@apache.org wrote:
> >> Author: jmsnell
> >> Date: Tue Jun 27 20:08:03 2006
> >> New Revision: 417652
> >>
> >> URL: http://svn.apache.org/viewvc?rev=417652&view=rev
> >> Log:
> >>
> >>  Content.getValue() with type="xhtml" ... now returns the serialized string without the wrapper div
> >>  Content.setValue() with type="xhtml" ... now automatically adds the wrapper div (regardless of whether or not the value param already has a div
> >>
> >>  This automatically bubbles down to entry.getContent(...) and entry.setContent(...)
> >>
> >>
> >
>