[PubSub] [Fwd: Re: [Standards] Pubsub extension idea]

Peter Saint-Andre stpeter at stpeter.im
Thu Apr 16 16:49:44 CDT 2009

Wrong list again, sorry.

-------- Original Message --------
Subject: Re: [Standards] Pubsub extension idea
Date: Thu, 16 Apr 2009 15:48:04 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Extension Discussion List <standards at xmpp.org>
References: <49546D27.3060603 at yahoo.com>

On 12/25/08 10:35 PM, Brett Zamir wrote:
> Hi,
> Along the lines of how Data Forms types and Data Forms Validation can
> influence display of forms, I'd like to see some standard way in which
> Pubsub payloads could be similarly extensible, not only by allowing
> different namespaces (as is now allowable within Atom extension elements
> or for a wholly different root namespace), but by some extensible
> standardization which could give more hints than either of these at
> input and display type. Data Forms & Data Forms validation might
> themselves be used as a payload, but I can see a need for more types
> targeting display of different types of GUI elements. For example, it
> would be nice to know whether an uploaded file (which could use
> sipub:file-transfer as the datatype) should be suggested as an image, an
> iframe, a link for download, etc.. This would allow:
> 1) As with DF, a uniform way to know how to display payloads
> 2) Allow semantic extensibility while also being able to suggest a
> display mode when the semantic namespace is not recognized.
> However, even with DF + DFV, there would need to be some way to indicate
> that DFV was also supported (if these are kept as separate specs), since
> Pubsub only allows for specification of one payload namespace--this
> might, I imagine, be done by requiring that both namespaces be supported
> if used as a Pubsub payload or, even better, by adding an option to
> Pubsub to indicate additional sub-namespace(s) that are
> required/supported).
> While Atom is extensible, there is no way to make a meta-data query to
> know what inner namespaces are supported (or to specify which ones
> during Node configuration), so DF+DFV (or any other option) is not so
> suitable as an Atom extension. DF + DFV could be used as the root, even
> indicating Atom namespaces+type within <field var>, but again, there
> would be no way to detect ahead of time which semantic namespaces (such
> as Atom) were being used within DF+DFV without first accepting the payload.
> Thus I'd like to suggest
> 1) a list-multi option be added to Pubsub to allow additional supported
> sub-namespaces to be indicated (whatever the top-level namespace).

Doesn't that break the rule of one namespace per node?

> 2) Data Forms and DFV be extended to offer greater specificity in types
> suggesting various input and display elements. (Maybe some existing GUI
> kit could be used as the basis for such a namespace.)
> Also, I think it might be nice to have an option to be able to indicate
> whether the namespaces (or subnamespaces) were required for proper
> viewing, or just supplementary.

I don't see a strong use case for this yet.


Peter Saint-Andre

Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090416/fbdec4fd/attachment.bin 

More information about the PubSub mailing list