[Standards-JIG] Re: JEP-0060 (pubsub) node configuration

Peter Saint-Andre 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 
> 2):
>   The field is intended for data description (e.g., human-readable text such 
>   as
>   "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/>
>   child.
> 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 mailing list