RE: [emergency-msg] CAP dictionary issues (was Re: [emergency-msg] SC meeting reminder)

Hello everyone,

I have a few comments on linking in CAP.

Following up on these comments made recently:

> >Cap:info_url: It seems too limiting to have only three types of URLs
> (HTML,
> >image, and audio). I would like to consider allowing multiple
instances
> of
> >arbitrary types.
> 
> The problem with arbitrary types, of course, is that it's hard to
> build applications to process binaries without some advance notion of
> what they might be.  If there are other types we envision wanting to
> support, we should probably add them explicitly now so implementers
> can take advantage of them.

I think XLinks would be a good solution for linking in CAP. XLinks have
features that make it possible to annotate the data being referenced to.
The xlink:role attribute is often used to contain the MIME type of the
remote resource.

You could have one linking element and use annotation to distinguish
between the various types of resources.

For example:

Instead of:
<info_url>http://www.dhs.gov/dhspublic/display?theme=29</info_url>
<image_url>http://www.dhs.gov/dhspublic/getAdvisoryImage</image_url>

You could use the xlink:role to distinguish between the two:
<url xlink:href="http://www.dhs.gov/dhspublic/display?theme=29"/>
<url xlink:href="http://www.dhs.gov/dhspublic/getAdvisoryImage"
xlink:role="http://www.isi.edu/in-notes/iana/assignments/media-types/med
ia-types/image/gif"/>

This makes for a much more flexible way of linking and also allows
applications to deal with the links more effectively based on the MIME
types (e.g. pdfs, zip files, video files).

By putting the type of link in an attribute and not the element name,
you do not limit the types of resources you can point to. Otherwise,
things could get quite messy if someone wanted a pdf_url, video_url, and
so on.

Hope this helps,

Nasseam Elkarra
http://www.opensec.org/