Re: [wsrp] Types for names

[Rich Thompson <richt2@us.ibm.com>]

I could easily see not changing ItemDescription.itemName
for the same reasons I argued for not changing the various ResourceList
oriented names ... they are already well localized by their usage.

Rich

Rex Brooks <rexb@starbourne.com>

05/27/05 09:30 AM

To	Rich Thompson/Watson/IBM@IBMUS, "wsrp" <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] Types for names

ItemDescription.itemName could get tricky without a URI,
though for our purposes, it may not be since we don't ecourage streaming
or one-way broadcast and SwA may be sufficient for our purposes at this
point, but I will have to look at this some more and I would like any information
you can give me on the problem I face:

We used derefURI in CAP (Common Alerting Protocol 1.0-out
now and 1.1 just went into public comment) and will be using it in EDXL,
where it may become even more problematic. Since I am not personally concerned
with one-way broadcast, I haven't had a great interest in it, but I can
certainly vouch for the fact that that community can raise cane over it
if it intersects their needs where they don't want, need or accept a requirement
to have a secure operational internet front end for their systems.

Oddly enough wireless actually seems to actually make
this worse, since it adds more protocols for them to handle. I can understand
the concerns of the few occasionally peevish geeks that I work with in
this area where one standard or another causes them heartburn, but at some
point the decision makers ought to be getting the message that they will
need to adapt to this technology and the sooner the better.

However, when that will be and whether or not reliance
on derefURI is the best way to handle it, I don't know, so my question
is: Will the lack of a URI impact this if I want to have a system that
pushes CAP or EDXL to the one-way broadcast community for disseminating
vital emergency messages? I have been been pushing WSRP into this community
for the last two years and it is likely to get better traction if it doesn't
break existing mechanisms, however few and far between they are right now.

I don't think it would matter, but it tweaked my anttenae.

Ciao,
Rex



At 6:38 AM -0400 5/27/05, Rich Thompson wrote:
It came up on the Interfaces SC yesterday that we ought
to tighten up the fields where names are defined as a number are currently
typed as xsd:string and xsd:QName is often more appropriate for avoiding
name clashes. A scan of the spec suggests the following fields be changed:

ItemDescription.itemName? -> text currently suggests this be
a URI ... would a QName be better?
PropertyDescription.name
Property.name
ResetProperty.name
NamedString.name? -> gets used for mimeHeaders and form parameters,
but a QName is allowed to have a missing prefix

I am not including the ResourceList related name fields as those are highly
localized and therefore should not suffer from name clash issues (at least
none that the Producer can not completely manage).

Rich


-- 

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309