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
