OASIS Open Mailing List Archives  ·  All Lists  ·  emergency-if  ·  2010-04

emergency-if — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

ValueListURN/URI Proposal


Rex- I appreciate what you are saying, but that proposition limits my system's use of the DE. My system shouldn't have to inspect each of the valuelists of the content objects to do routing and exposure. You did bring up a few points that I would like to bring out: 1. Scalability - this is tossed around a lot. Pub/sub doesn't scale big naturally. Your view is that the DE will provide a mechanism for a pub/sub system to scale, which I agree with. Requiring a URN in one of the list values, has nothing to do with scalability. If you think I'm wrong...show me an architectural sketch of a system that uses urn's where just any old unique string wouldn't work. 2. Security - Proponents of the URN only solution argue that it is more secure. Besides doubting that fact, I would like to point out that not every Emergency Management system HAS to be at a DNDO level of security. Again I make the point that you will have to parse that string one way or another at your router. Right now it is just a string, so you have to parse it anyway...Once again show me a system diagram of what requires URN versus unique string. If you are the super-secure system just copy paste this code: if (!ValueListURN.StartsWith("URN", true, new System.Globalization.CultureInfo("en-us"))) DropMessage(); My point is that I can hand-draw the 10,000 foot view of my system on my whiteboard and snap a picture with it to email out which makes my case for what I want to do. I made a lame attempt at putting together those visio things (which was about 15min of effort) to make my case, but I've gotten no solid technical evidence to support the claims of the URN camp. I understand the technical issues thoroughly that are made as claims for a URN only solution, however the idea that these technical issues dictate a URN-only solution just aren't there. I'll propose a different solution: 1. Move the following into its own "routing" sub-element of the DE which would be optional: - this would allow the super-secret routing systems to go right here for all their goods. The rest of us could just ignore this structure when we parse the DOM. Senderrole Recipientrole Keyword Distributionreference explicitaddress 2. Add a generic structure in the root DE element that would allow me to: Have a unique name (String) Have values for that (String) Specify What I'm talking about (String) This solution: 1. Would allow us lesser folks to do all the stuff in the routing sub-element on a small scale. 2. Wouldn't increase the size of the root de element (actually it would reduce it). 3. Still allow the URN camp to lock down the routing portion of the DE One other alternative is just leave it as a string, the way the 1.0 committee had it. Ironically the first example in the DE 1.0 document uses a URL in the ValueListURN item. I'll just plug whatever I want in there and be done with it. Then we'll have a bunch of super-brittle systems out there. That will really help those of us actually building systems for First Responders. -Don Office: 315-838-2669 Cell: 315-383-1197 [email protected]

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]