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.
