Re: [emergency] MPEG (was Re: [emergency] usage scenarios)

[Kon Wilms <kon@datacast.biz>]

On Thu, 2005-08-18 at 15:15 -0700, Art Botterell wrote:
> Hmmm... well, that's a pretty basic question.  I thought the whole  
> idea of the Distribution Element was to provide a consistent  
> "transport mechanism" for various types of content.  Is that whole  
> idea what you object to, or is it specifically the idea of moving non- 
> XML content as part of the package, or is it something else?

Well, the fact that it allows for embedded data, namespaced data, and
external data doesn't make it a consistent transport mechanism. That's
not a bad thing though.

I object to the idea of using the derefuri capability as a quick and
dirty way to use the EDXL file to transport all relevant data on the
network. If data can be referenced or delivered by other means then it
should not be encoded into the payload. 

URI and namespacedxml content should be the primary content access
methods. Derefuri should only be used as a last case resort. The CAP
spec has derefuri labeled in a 'only use in these circumstances' method
- the EDXL derefuri should be the same.

> For example, do you see a difference in the appropriateness of  
> including a Word binary as opposed to including it in an XML format?   
> Or of including a GML file versus the equivalent shapefile?  Or a  
> photo versus a moving image?

Those all fall into the same category -- data blobs. (see below)

> Guess I'm trying to get a clearer understanding of what rule you'd  
> use to draw a line.

If data is accessible on the network via other URI location then it
should not be inserted as base64 data into the message.

> > I recall an RF demo some time back where FEMA stipulated to us that  
> > the
> > messages be delivered within two seconds of their origination.
> 
> That's a good example of a functional requirement for a particular  
> application, but not for the standard as a whole.  It imposed an  
> additional performance requirement on that specific implementation,  
> certainly, but I'm not clear on why we would impose that requirement  
> on all other users.

That example is not to be taken literally -- it is about efficiency. The
moment you insert data blobs into a message you degrade storage and
network capabilities. And moreso for anything processing the content,
because the derefuri data has to be decompressed to memory or disk,
hence you are eating > 2x the disk space or memory of the original
message.

I can't think of any reason why someone would want to just stick
derefuri data into an EDXL message when that derefuri data can be
obtained or referenced by other means. Well, except if one wants to take
the easy way out and not have to deal with the intricacies of how to
reference and get said data to the location that is viewing the EDXL
content.

Hope that makes sense...

Cheers
Kon