Return-Path: Delivered-To: apmail-incubator-abdera-dev-archive@locus.apache.org Received: (qmail 37141 invoked from network); 29 Jun 2006 09:12:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 Jun 2006 09:12:04 -0000 Received: (qmail 59426 invoked by uid 500); 29 Jun 2006 09:12:04 -0000 Delivered-To: apmail-incubator-abdera-dev-archive@incubator.apache.org Received: (qmail 59392 invoked by uid 500); 29 Jun 2006 09:12:04 -0000 Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: abdera-dev@incubator.apache.org Delivered-To: mailing list abdera-dev@incubator.apache.org Received: (qmail 59383 invoked by uid 99); 29 Jun 2006 09:12:04 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 02:12:04 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jasnell@gmail.com designates 66.249.82.198 as permitted sender) Received: from [66.249.82.198] (HELO wx-out-0102.google.com) (66.249.82.198) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 02:12:03 -0700 Received: by wx-out-0102.google.com with SMTP id t13so49487wxc for ; Thu, 29 Jun 2006 02:11:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MghGjq2n2nNC1e0k50WFsgA5YcL2hHli34+L5vdKHeasjLLOGcIlg6kME3NtKrn6/TWLyU4qX+u8hTTc5WxsHQiPU3tY9mY3rs1qEjUEaGet6M35vshJtsY/iWUZd5q5OQohFCKTu0p1x63zxyIkfpZU6CEakNbEWlFChYXEIug= Received: by 10.70.65.10 with SMTP id n10mr2761840wxa; Thu, 29 Jun 2006 02:11:42 -0700 (PDT) Received: from ?63.118.136.51? ( [63.118.136.51]) by mx.gmail.com with ESMTP id h19sm322234wxd.2006.06.29.02.11.42; Thu, 29 Jun 2006 02:11:42 -0700 (PDT) Message-ID: <44A3994D.6040608@gmail.com> Date: Thu, 29 Jun 2006 02:11:41 -0700 From: James M Snell User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 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 References: <20060628030804.777DF1A983A@eris.apache.org> <44A1FF85.1010800@torrez.us> <44A2721A.2000103@gmail.com> <905f7c910606281829s18ca8dch7d8bd044f86b68d5@mail.gmail.com> In-Reply-To: <905f7c910606281829s18ca8dch7d8bd044f86b68d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Ok, so I checked in a change last night that actually reverses this. The default getValue/setValue will "do the right thing" with regards to stripping the div. The Content and Text interfaces now have getWrappedValue and setWrappedValue methods that return the div and expect the div. Yes, it's a bit wierd, but because the Atom spec requires special handling of xhtml content (for reasons I personally think are rather silly) this seems to be a somewhat sane approach. Let me know if it causes you any additional pain. :-) - James Elias Torres wrote: > Cool. > > On 6/28/06, James M Snell 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(...) >> >> >> >> >> > >> >