Hi, 2016-02-24 13:35 GMT+01:00 Kevin Smith <[email protected]>:
> On 24 Feb 2016, at 11:57, Daniel Gultsch <[email protected]> wrote: > > 2016-02-14 22:33 GMT+01:00 Daniel Gultsch <[email protected]>: > > I would like to see this XEP support more or less arbitrary attributes > like content-type, content-length as well as resolution (x,y) for images > and videos as well as runtime for audio that can be used when referencing > files on HTTP hosts. > > > > The twitter API on which this is based on does this as well. > > > > Is this something that could be included in this XEP? And maybe have the > XEP include a list of some standard attributes and their meaning. > > > > I've been planing to provide a way to annotate HTTP file links and I > think it would be great to implement this in the same XEP. (HTTP Upload and > link sharing is already seeing wide adoption (Conversations, gajim, monal, > xabber)) > > > > I still have the requirment that i need to 'annote' (or 'reference' if > you will) data like URLs in the body tag with information like > content-type, content-lenght and so on. > > > > If you don't want this in the references XEP I'm fine with this and I'm > gonna create my own. However I believe this would mix quit well especially > since twitter does the same thing. > > > > Having arbitrary (XML) attributes is probably a problem schema wise. So > a slightly modified version of my earlier proposal would be to have a data > form child of the reference element and a (growing) list of well known > fields. > > > > Kev: Is this something you'd be willing to include in your XEP? If you > like I'd even add it myself and create a PR. If not can I get a 'No' so I > can create my own XEP to fullfill this need? > > Sorry, I should have replied earlier. I’m not sure about the data forms > idea, but the basic premise of marking up bits of the body is what the > spec’s for. > > What’s the reason that arbitrary attributes are needed? (Sorry, I’m > possibly being dense) They don't necessarily have to be completely arbitrary. I just figured it's easier and makes all this downwards compatible without changing namespace when adding more attributes in the future. If we annotate the link target it is impossible to see what kind of meta data will be required. We might start with size and content type but attributes like run time (movies, audio) and resolution are also perfectly reasonable. Depending on the use case something like audio codec or bitrate. I personally wouldn't use them but maybe someone else will. My point is that data forms and known fields are more flexible than xml attributes. But I'd be fine with a simple <attr name="content-length">1234</attr> as well. The data forms just came from the idea of reusing existing structures. cheers Daniel
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
