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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


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


On Aug 18, 2005, at 8/18/05 2:21 PM, Kon Wilms wrote:
> This is not so much to do with bandwidth implications as it is to do
> with using XML as a cheap and easy transport mechanism. It is not a
> transport and really should not be used as one.

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?

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?

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

> As for future implementations, due to the fact that EDXL will be  
> routed
> over a multitude of networks implies that the size of the message will
> always be limited by the lowest bandwidth capability of any recipient.

While that's true in the aggregate, I'm not sure that's the same as  
saying it's the case in each and every instance.  And even if it  
were, implementers could use intelligent gateways to protect low-rate  
networks from over-bulky content rather than us reducing everyone to  
the least common denominator.  (And what would we consider that  
lowest bandwidth capability to be, exactly?)

> 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.

> No matter
> the size of the pipe and transport mechanism, a large message with
> embedded content will take longer than 1 second to process on each  
> side
> of the link. And the same issue would be faced by implementers not  
> using
> RF delivery.

Well, doesn't that depend on how we define a "large message"... and  
also on our assumptions about the current state of processing  
capacity, which might change in the future?  Anyway, it seems to come  
back to an issue of size/capacity here.  Personally I'm inclined to  
think that's beyond the scope of this particular specification.

> What
> about that one variable that is overlooked and leads to the message  
> not
> being delivered in a timely manner to a recipient that really needs  
> it?

I don't think it's overlooked, so much as I think we've assumed that  
it's beyond the scope of a content standard to fix performance  
specifications for applications that might not even have been  
envisioned yet.  The definition of "timely" seems, to me at least, to  
vary from application to application, and I don't know how we'd go  
about fixing that parameter for everyone, even if we wanted to.

- Art




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