Re: [Standards] magical pubsub metadata item
On 06/12/2012 05:19 AM, Peter Saint-Andre wrote: On 6/10/12 5:08 AM, Sergey Dobrov wrote: On 06/10/2012 04:44 PM, Sergey Dobrov wrote: On 06/08/2012 10:41 PM, Peter Saint-Andre wrote: I see the following reasons here: 1) some of these fields have more complex types that just a string. For example, atom:title can contain xhtml data and then it has to have a type attribute there, category field can contain attributes term, scheme and label, and so on. 2) We are losing in flexibility very significantly: 2.1) why nodes with not an atom payload should receive these fields when configuring? 2.2) what shall we do if we will faced with the same problem for another payloads? Our configuration form is already very huge. For example, you mentioned XEP-84, why not add fields bytes, id, height, type, width into the form too to avoid extra node as excessive? Actually, I think that we have now metadata form which can be edited by human and we should not mix that with payload specific metadata which should not be edited by human. The result will be ugly: form will become usefulness for both of these things. So I think we should add some sticky item for that and that will be more flexible and clear way. I really don't think that splitting node into two different nodes (payload+metadata) is a good idea because it takes away node's information value. Even node with just answers to the post can be read as independent node but not a node without metadata. OK, well, you could copy XEP-0221 as a start toward the 'xml' field type. :) I started to do that and then I had a question: what is the level we must correspond to the Atom specification? Can we avoid some things that we have done with the other ways? I mean the atom:updated field which is disturbs me in the blog metadata because it needs to be updated frequently but I don't want to force clients to do that because it will make them more complex and the thing is actually dummy because we have other mechanisms (like instant events and pubsub since) to solve problem that atom:updated solves. So can we avoid atom:updated there? Should we change the namespace if so? Another things that probably can be excluded: 1) atom:title because we have a replacement in the node configuration. But that can hurt if we will import some atom feeds back into pubsub. 2) atom:author because we can use vcard instead of this. But the problem is the same like we have in the first thing. Maybe we can declare that things as optional with a fallback to node metadata values. Actually, I thought about avoiding the xml field at all but I still see some reasons to keep it there: we can use some atom extensions and it's more flexible to put node relations there than make extra node configuration fields. P.S. I start to think that it would be easier to solve questions at real-life meeting because I still have very large amount of problems we didn't discussed yet but we had to have the solutions a long time ago :) Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] magical pubsub metadata item
On 6/10/12 5:08 AM, Sergey Dobrov wrote: On 06/10/2012 04:44 PM, Sergey Dobrov wrote: On 06/08/2012 10:41 PM, Peter Saint-Andre wrote: I see the following reasons here: 1) some of these fields have more complex types that just a string. For example, atom:title can contain xhtml data and then it has to have a type attribute there, category field can contain attributes term, scheme and label, and so on. 2) We are losing in flexibility very significantly: 2.1) why nodes with not an atom payload should receive these fields when configuring? 2.2) what shall we do if we will faced with the same problem for another payloads? Our configuration form is already very huge. For example, you mentioned XEP-84, why not add fields bytes, id, height, type, width into the form too to avoid extra node as excessive? Actually, I think that we have now metadata form which can be edited by human and we should not mix that with payload specific metadata which should not be edited by human. The result will be ugly: form will become usefulness for both of these things. So I think we should add some sticky item for that and that will be more flexible and clear way. I really don't think that splitting node into two different nodes (payload+metadata) is a good idea because it takes away node's information value. Even node with just answers to the post can be read as independent node but not a node without metadata. OK, well, you could copy XEP-0221 as a start toward the 'xml' field type. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] magical pubsub metadata item
On 06/08/2012 10:41 PM, Peter Saint-Andre wrote:
On 6/8/12 3:56 AM, Sergey Dobrov wrote:
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
I see the following reasons here:
1) some of these fields have more complex types that just a string. For
example, atom:title can contain xhtml data and then it has to have a
type attribute there, category field can contain attributes term, scheme
and label, and so on.
2) We are losing in flexibility very significantly:
2.1) why nodes with not an atom payload should receive these fields when
configuring?
2.2) what shall we do if we will faced with the same problem for another
payloads? Our configuration form is already very huge. For example, you
mentioned XEP-84, why not add fields bytes, id, height, type, width into
the form too to avoid extra node as excessive?
Peter
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
Re: [Standards] magical pubsub metadata item
On 06/10/2012 04:44 PM, Sergey Dobrov wrote: On 06/08/2012 10:41 PM, Peter Saint-Andre wrote: I see the following reasons here: 1) some of these fields have more complex types that just a string. For example, atom:title can contain xhtml data and then it has to have a type attribute there, category field can contain attributes term, scheme and label, and so on. 2) We are losing in flexibility very significantly: 2.1) why nodes with not an atom payload should receive these fields when configuring? 2.2) what shall we do if we will faced with the same problem for another payloads? Our configuration form is already very huge. For example, you mentioned XEP-84, why not add fields bytes, id, height, type, width into the form too to avoid extra node as excessive? Actually, I think that we have now metadata form which can be edited by human and we should not mix that with payload specific metadata which should not be edited by human. The result will be ugly: form will become usefulness for both of these things. So I think we should add some sticky item for that and that will be more flexible and clear way. I really don't think that splitting node into two different nodes (payload+metadata) is a good idea because it takes away node's information value. Even node with just answers to the post can be read as independent node but not a node without metadata. Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] magical pubsub metadata item
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. So I think that the best way is to use #2. Or #3 if we will define a way to stick nodes together to prevent a sparseness. Peter -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] magical pubsub metadata item
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/
Re: [Standards] magical pubsub metadata item
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/
Re: [Standards] magical pubsub metadata item
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? Peter -- Peter Saint-Andre https://stpeter.im/
