[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]