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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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


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


Maybe someone could educate me on how XLinks would be implemented in 
this particular case?

But I think the first question needs to be whether linking, however 
implemented, is really the best way to go in this application.  Some 
folks have suggested that it might raise potential data-integrity 
concerns.  Plus, of course, there's no way to utilize links over a 
one-way (e.g., broadcast) transport.

If we decide that links are the way to go, then how to implement them 
is the obvious next question.

In any event, I'd like to suggest that we focus today's (necessarily 
brief) phone call on nailing down the <area/> block, so we'll know 
what we can count on from that component as we build upon it.

That means we'd have at least a week for the "whether/how of links" discussion

- Art


At 9:31 AM -0400 6/3/03, R. Allen Wyke wrote:
>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: emergency-msg-unsubscribe@lists.oasis-open.org
>>  For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org
>--
>R. Allen Wyke
>Chair, Emergency Management TC
>emtc@nc.rr.com
>http://www.oasis-open.org/committees/emergency
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-msg-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-msg-help@lists.oasis-open.org



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