On 5/30/12 1:07 PM, Sergey Dobrov wrote: > On 05/31/2012 01:51 AM, Peter Saint-Andre wrote: >> On 5/30/12 12:24 PM, Sergey Dobrov wrote: >>> On 05/31/2012 12:02 AM, Peter Saint-Andre wrote: >>>> changing the subject... >>>> >>>> On 5/30/12 3:07 AM, Sergey Dobrov wrote: >>>> >>>> The main problem I see here is that the data you get with item='meta' >>>> would have a different schema than all the other items in the node. >>>> This >>>> is not true with the singleton node model (item='current'). For that >>>> reason alone, I think it would be best to use the existing mechanism we >>>> defined for retrieving the node metadata: >>>> >>>> http://xmpp.org/extensions/xep-0060.html#entity-metadata >>> >>> As I mentioned before, I think that this mechanism is not suitable to >>> solve the problem because we have no place to put XML payload there. But >>> that can be solved if we will invent some field to put it. >> >> Aha, OK. I didn't understand that from your previous messages. Sorry. >> >> Yes, we could define a field type of "xml", similar to the media field >> type in XEP-0221. Another option is to define addition fields to be >> included in the data form. What information do you want to include? > > I want to store in metadata any things that can be stored in atom:feed > (and not in atom:item). As I said it will store such things as blog > name, author (so we can not repeat them in each item and update easily) > or link to a post if it's a comments node. It might be useful to have > ability to inform subscribers about changes in the metadata too (but > this is not necessarily). I don't think that we can add necessary fields > to the data form because it will be strongly depend on the node payload > type and will be useless for other payloads, so we will lose flexibility.
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. Peter -- Peter Saint-Andre https://stpeter.im/
