[Standards-JIG] Re: JEP-0060 (pubsub) node configuration
stpeter at jabber.org
Tue Jan 18 21:07:38 UTC 2005
In article <20050103211104.GA79845 at localhost>,
Ralph Meijer <jabber.org at ralphm.ik.nu> wrote:
> On Mon, Jan 03, 2005 at 04:04:55PM -0500, Bob Wyman wrote:
> > Ralph Meijer wrote:
> > > I had thought a service would only sent a form (after node creation)
> > > containing the fields a client can actually change. For seeing the
> > > static data, the more complete form can be retrieved using
> > > disco#info's meta-data attachment.
> > We've been returning forms that contain all the current
> > configuration items with the non-modifiable stuff in fixed fields. It seems
> > to work well for us and is very simple to understand.
> > I'm concerned that distinguishing between the static and non-static
> > data is going to increase complexity significantly as well as require more
> > round-trips without giving us a great deal of benefit. Can you provide
> > additional justification for requiring that different methods be used for
> > each kind of data?
> Well, first of all, static data is not configurable, so while it might
> such data might be properties of a node, they are not options.
> Second, the fixed field type is not meant for data in this way, but really is
> only for presentation. This is written in the JEP-0004 specification (table
> The field is intended for data description (e.g., human-readable text such
> "section" headers) rather than data gathering or provision. The <value/>
> child SHOULD NOT contain newlines (the \n and \r characters); instead an
> application SHOULD generate multiple fixed fields, each with one <value/>
> Unlike for example in HTML, there is no way to specify an x:data field as
> 'read only'.
Hmm. Personally I don't have any strong objections to what Bob is doing
with "fixed" fields. Perhaps JEP-0004 is not worded carefully enough on
this point. One could certainly understand a read-only field (e.g., the
creation time or whatever) as a kind of "data description" (per table 2
in JEP-0004) rather than a kind of "data gathering" (there is no data to
gather, but the system is telling you what the current value is). My
understanding of JEP-0004 is that it was intended to be quite flexible
for implementors, and using "fixed" in Bob's way seems consistent with
that intent. In particular, I don't think the text that you've cited was
intended to limit "fixed" fields in the way you suggest.
More information about the Standards