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

I would agree with Nasseam on this one - using an already
defined/established standard for linking would be a good thing.
Additionally, for the creation of ICS forms you guys should review
XForms to see if their is a fit.

I have cross posted this to the EM IF SC in case they have interest in
this as well.

Allen

On Tue, 2003-06-03 at 05:02, Nasseam Elkarra wrote:
> 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/
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 
-- 
R. Allen Wyke
Chair, Emergency Management TC

http://www.oasis-open.org/committees/emergency