OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: WG: Issue: Attribute Multiplicity


Peter (et al),

At 08:48 AM 1/19/01 +0100, Zimmermann, Peter wrote:
>Hi all,
>
>some little comments/questions on Lofton's proposal:
>*       Why should name be multiple?

First, I listed it as multiple because that is how I remember the 
discussion/decision from 2 years ago.  In other words, I'm not arguing that 
it should/shouldn't be multiple, but rather that is what we decided earlier 
and intended for WebCGM 1.0.

>Is it intended to hold several natural
>language variants?

Okay, now I'll argue for multiplicity.  I guess natural language variants 
could be one application (or those could be in an external companion 
file).  But different people have different ideas and applications for 
'name'.  One common idea is that it can be used to define an object as 
belonging to a set of similar objects (or being an object of a given type), 
for example 'lug nut' on a wheel.  Multiple 'name' attributes on a single 
object gives the functionality that the single object can participate in 
multiple, possibly non-hierarchical relationships.

I recall this requirement from the 'name' discussions of 2+ years ago.

>*       Sure, multiple attribute occurrences can't be expressed in XML as
>such, but there are two other alternatives:
>         - use elements in the companion metadata (which I would prefer), or

Yes.  However one popular current view about 'name' is that it should be in 
the WebCGM, not the companion file, because it is a possible target 
specifier in the URI fragment specification.  Hence it is good for the 
viewer to have quick and direct access to 'name', for pick and other 
navigation functions.

>         - use attribute type NMTOKENS (limited char set as you need to have
>separators, e.g. spaces).

This is something you could bring up for the Monday teleconference to 
resolve the char-set details.  I don't think anyone has proposed this 
yet.  It allows the "punctuation" characters "_", ".", "-", ":", and it 
allows SPACE, but it prohibits all the others (like "+", "{", etc).

-Lofton

*******************
Lofton Henderson
1919 Fourteenth St., #604
Boulder, CO   80302

Phone:  303-449-8728
Email:  lofton@rockynet.com
*******************



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC