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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: Re: [wsrp] Types for names

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.


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?
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).


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]