That works. The agencies can then work out what information
they wish to share. I note also the Microsoft work on Regional
Area Information Networks (RAIN). I am not familiar with the
details. This has to be done on a case by case basis given
the fairly substantial differences among agencies in given
communities. Standards for statistical data reporting (say
UCR or NIBRS) are quite good. Standards for interagency
information sharing content are nascent in some cases and
well developed in others (say agency to state requests for
names and vehicle information through state message switches
and NCIC).
The shared report requirements are pretty good but vary by
state and then, one has to hope the local agency is using
the state standards.
Just FYI: most permissions over files are role and group based
within an agency. I would expect the portal to reflect that.
len
From: Rex Brooks [mailto:rexb@starbourne.com]
This is all true and about to change, hopefully for the better, very
soon. Karl Best made several announcements yesterday of
specifications now submitted for voting upon as OASIS-wide standards,
and one of them is WSRP, Web Services for Remote Portlets. While this
deals mainly with Portals per se, it seems likely that most web
services will employed within such a structure for just these access
control and security reasons, and for achieving the ability to define
permissions within producer, consumer and user contexts
appropriately. This spec was designed in conjunction with JSR168, the
Java Portlet spec, to ensure a wider applicability and has been
tested with J2EE and .Net.
It should be noted that registries are going to be quite useful, but
need only be starting points for more complete negotiations and
contracts. Some will, some won't. UDDI and ebXML are there now and
can be added to.
CAP will be ready sooner rather than later. That sets the stage for
some fairly important developments.
Ciao,
Rex
At 12:41 PM -0500 7/29/03, Bullard, Claude L (Len) wrote:
>Right. In industry, the keiretsu phenomenon dominates.
>One needs not just partners, but credible partners.
>And rules are very different given the process, say
>a procurement offer vs a services offer, and so on.
>UDDI doesn't help much here and it can actually make
>it much tougher to negotiate a good deal.
>
>The same can be said of public safety agencies, but one
>questions if that can be maintained in the face of current
>events and requirements. However, what the public safety
>groups as a whole should be discussing are the services
>that can be exposed more or less across agencies of
>different types because this cannot be based on the
>data they create or share. As you know, the Internal
>Affairs group cannot expose name or incident information
>to other internal agencies. Dissemination Management
>is required to ensure redaction of information shared
>to the public given a juvenile, for example, and so
>forth. So the business rules for standard services
>have to be worked out. A registry is fairly easy
>given that.
>
>len
>
>
>From: Aerts, John F. [mailto:jfaerts@lasd.org]
>
>Yvonne L. Lee and David Rubinstein, Software Development Times
>
>A few years ago, when Web services were envisioned as creating
>interconnected applications that spanned across businesses, public
>Universal Description, Discovery and Integration (UDDI) registries
>were seen as a tree on which to find the fruit -- or external Web
>services. Now that Web services are used almost exclusively for
>internal development and integration, not only has the hype
>surrounding the public UDDI registries subsided, but the
>information in them hasn't grown either.
>
><http://sdtimes.com/news/082/special2.htm>
>
>
>
>You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
o
>up.php
>
>You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
oup.php
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request