You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by Elias Torres <el...@torrez.us> on 2006/06/28 06:03:17 UTC
Re: svn commit: r417652 - in /incubator/abdera/java/trunk/parser/src/main/java/org/apache/abdera/parser/stax:
FOMContent.java FOMDiv.java
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(...)
>
>
Re: svn commit: r417652 - in /incubator/abdera/java/trunk/parser/src/main/java/org/apache/abdera/parser/stax:
FOMContent.java FOMDiv.java
Posted by James M Snell <ja...@gmail.com>.
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 <ja...@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(...)
>> >>
>> >>
>> >
>>
>
Re: svn commit: r417652 - in /incubator/abdera/java/trunk/parser/src/main/java/org/apache/abdera/parser/stax: FOMContent.java FOMDiv.java
Posted by Elias Torres <el...@torrez.us>.
Cool.
On 6/28/06, James M Snell <ja...@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(...)
> >>
> >>
> >
>
Re: svn commit: r417652 - in /incubator/abdera/java/trunk/parser/src/main/java/org/apache/abdera/parser/stax:
FOMContent.java FOMDiv.java
Posted by James M Snell <ja...@gmail.com>.
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(...)
>>
>>
>