[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Perspective: XML's ticking time bomb



An example where translations wouldn't work would be one vendor who
counts packets on an interface while another counts bytes. There is no
algorithmic translation between these. Nevertheless, there are many
examples where translations are possible. Typically, we are concerned
with scenarios where a new protocol or technology is developed. The
technology and its related standards would dictate what the management
interface exposes. If the technology is well-defined and implemented in
a similar way across products, it follows so would the semantics of the
underlying management model.

The semantics always vary, nothing will change that. It is in many cases
value-add for vendors. The question is: how much semantic overlap
exists? If the overlap is substantial, then algorithmic translations
follow. What we don't need is a large number of complicated,
transport-specific, and incompatible syntaxes to make even the tractable
part of the problem intractable... Such is the state of the industry
today.

-Dave

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> Sent: Tuesday, January 07, 2003 11:53 AM
> To: Durham, David
> Cc: xmlconf@ops.ietf.org
> Subject: Re: Perspective: XML's ticking time bomb
> 
> 
> >>>>> Durham, David writes:
> 
> Dave> So your schema can define "<IntFace> UP </IntFace>" and mine can
> Dave> define "<Interface> ON </Interface>" and XSLT can be used to
> Dave> translate between these. Or, better yet, when a standard is
> Dave> completed, vendors can easily provide translations from it to
> Dave> their existing models.
> 
> I think this example misses the point. It assumes that both boxes have
> the same understanding of the concept of an interface. And yes, as
> long as there is agreement on the underlying model, conversions of the
> syntax are doable.
> 
> However, without an aggreed underlying conceptual model, conversions
> will be hard and painful and XML won't be a good enough pain killer.
> 
> /js
> 
> --
> Juergen Schoenwaelder    <http://www.informatik.uni-
> osnabrueck.de/schoenw/>

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>