[Standards] Proposed XMPP Extension: References
daniel at gultsch.de
Wed Feb 24 13:40:14 UTC 2016
2016-02-24 13:35 GMT+01:00 Kevin Smith <kevin.smith at isode.com>:
> On 24 Feb 2016, at 11:57, Daniel Gultsch <daniel at gultsch.de> wrote:
> > 2016-02-14 22:33 GMT+01:00 Daniel Gultsch <daniel at gultsch.de>:
> > 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,
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards