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/
