Re: Issue 231 draft resolution - what attribute name?

Jacek Kopecky wrote:

> Hi all, 8-)
>this is a draft resolution text for issue 231 [1]. The WG has agreed to
>add an attribute that allows creating SOAP Encoding data that is
>self-descriptive in terms of its structure (simple values, structs or
>arrays can be marked as such).
>At the moment, we are trying to find the right name for the attribute.
>In the draft text below, the attribute is named 'valueType', other
>suggestions so far have been 'node', 'nodeType', 'valueClass',
>'content'. Please post your comments on the name.
I really don't care since I do not expect to put this on most messages 
that are schema-described -- my own use cases say this is the most 
common usage -- but when discussing something like this that can occur 
on every element, is it too late to explore brevity?  That shouldn't be 
an overriding concern, but if we can find something appropriate...

The values are, as I remember, one of array,struct,simple, at most 6 

Another attribute name that may appear alot is xsi:type -- four 
characters with at least two characters of prefix, totalling 6 characters.

How about leaving "value" out of the name.  We shouldn't have too many 
global attribute names of the encoding to worry about conflicts.

So in descending order by my preference:

since this identifies the form of the type.  We haven't defined this new 
concept of "form" anywhere else, but at least the term is not overloaded 
elsewhere in the specification.  Minimum of 6 characters with short 
prefix.  It seems to me to be a stretch to think lots of people will 
confuse this with the forms in web clients, which is the only possible 
conflict I can think of.

Most of the same advantages as enc:form, but it does not give me quite 
as nice a picture of the SOAP meta-type like form does.

A class is perhaps a meta-type.  This is one character longer, no 
overloading in the spec.  It seems likely that users might think this 
names the class of the programming object this element corresponds to, 
expecting to find a java or COM class name.

Same length as form, but very likely to be confused with existing type 
usage, such as xsi:type within the specification (even if it were 
valueType, which does not make an appropriate distinction why valueType 
is not xsi:type).

Ray Whitmer

Received on Thursday, 26 September 2002 09:57:19 UTC