On 6/8/12 3:56 AM, Sergey Dobrov wrote:
> On 06/08/2012 06:16 AM, Peter Saint-Andre wrote:
>> On 5/30/12 1:07 PM, Sergey Dobrov wrote:
>>
>> So we have at least three options:
>>
>> 1. Map the atom:feed elements to x:data fields.
>> 2. Define a generic "xml" field type, similar to XEP-0221.
>> 3. Use a separate metadata node.
>>
>> Do you see other options?
>>
>> As you say, #3 introduces atomicity issues.
>>
>> #2 would be very flexible, but it seems strange to have an unconstrained
>> "xml" field type inside x:data forms, since x:data forms were designed
>> as a way to constrain the normally unconstrained structure of XML. :)
>>
>> Therefore I lean toward #1.
>
> I see the following problem with the first option:
>
> If we will map fields then we will need to do separate fields set for
> different payload types which is hard to do with current XEP-60
> specification. On the other hand, if we will declare such fields for
> each payload we will get too much fields.
>
> We can try to use more general fields (i.e. just provide a field to
> describe parent node, that should be enough since we can get author
> information from his vcard) but we will not be compatible with the Atom
> specification that way.
I'm confused. Why can't we just re-use the following metadata fields
from Section 4.1.1 of RFC 4287 and place them in the x:data form
described in Section 5.4 of XEP-0060?
{http://www.w3.org/2005/Atom}author
{http://www.w3.org/2005/Atom}category
{http://www.w3.org/2005/Atom}contributor
{http://www.w3.org/2005/Atom}generator
{http://www.w3.org/2005/Atom}icon
{http://www.w3.org/2005/Atom}id
{http://www.w3.org/2005/Atom}link
{http://www.w3.org/2005/Atom}logo
{http://www.w3.org/2005/Atom}rights
{http://www.w3.org/2005/Atom}subtitle
{http://www.w3.org/2005/Atom}title
{http://www.w3.org/2005/Atom}updated
Peter
--
Peter Saint-Andre
https://stpeter.im/
