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).
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.
Brett
