wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Types for names
- From: Rex Brooks <rexb@starbourne.com>
- To: Rich Thompson <richt2@us.ibm.com>, "wsrp" <wsrp@lists.oasis-open.org>
- Date: Fri, 27 May 2005 06:30:25 -0700
Title: 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]