-----Original
Message-----
From: John
Strassner [mailto:John.Strassner@intelliden.com]
Sent: Thursday, January
09, 2003 3:49
PM
To: Durham, David; Faye Ly; Wijnen, Bert
(Bert); Xmlconf (E-mail)
Subject: RE: Perspective: XML's ticking
time bomb
I
disagree.
First,
where's the paradigm shift?
[DaveD]
XML has well-defined standards and tools for data transformation. It is the
common mode of operation to transform XML data from one form to another. It
makes component integration simpler. It also helps that it provides structured
data that is human readable as well, first popularized by the document markup
language SGML. What is the equivalent of XSLT for MIBs, or for MOFs, or MIFs,
etc?
<js> But this isn't a paradigm shift. This is the ability to do
something more efficiently. If we don't build the models, then we're
translating between different proprietary forms. Not interesting.
</js>
Second,
what you're describing in translation is exactly the same work that is
necessary to build a common model in the first place.
[DaveD]
How so? You mean excessive, never-ending churn? Well good, then we agree.
<js> Funny, but not
what I meant. Your argument was that XML is somehow better because it has
translation tools. My argument is that without a common model there is
nothing to guide the translation, and nothing to verify that the translation
is correct. We still have a Tower of Babel.
</js>
I don't
see how you can say that building a common model is impossible, but having
vendors agree on translations is.
[DaveD]
I didn't say it was impossible, just that a common model tends to be too late
to make a difference, and defacto standards will reign. XML simply allows the
process to be more flexible, where a snapshot of a developing model can be
implemented, and minor conversions from one model to another aren't a big
deal.
<js> Late, schmate. The
argument is specious. If the problem is that we have too many different
standards with different syntaxes, then surely the solution is to be able to
reduce this number. If we're reducing the number, we need to define
translations, which is the SAME work as defining common attributes, etc. of an
object model. I'm arguing that the work is the same. You seem to not like the
packaging of that work (into an object model). </js>
Third, I
don't see how different working groups in isolation can do either of
these.
[DaveD]
Either of these?
<js> a translation (in
isolation) or a translation among object
models
Finally,
you say:
"IMHO,
this group should focus on determining which XML schema definition language
IETF wgs will use, define the basic reusable data types useful across IETF
wgs, define the operational model for XML transactions, and select a common
transport. Just get the foundation in place & let the models work
themselves out over time in individual wgs and let XSLT be the glue between
the early products and late standards."
I
honestly don't see how this works, helps, or benefits anyone. Choosing a
syntax, and defining the data types used in that syntax, doesn't enable
interoperability. Selecting a common transport is immaterial, it just moves
bits around. And the hope that "the models will work themselves out over time
in individual wgs" is simply naïve - witness the ongoing painful arguments in
CCAMP, for example, between "IETF" and "ITU" "models".
[DaveD]
Yes, there are more "common models" than one can shake a stick at... That's the
point, there is nothing common about them, not the model itself, its
transport, its syntax, etc. There are already plenty of models... So let's make
the simple foundational stuff common, and allow it to be as simple as possible
to transform data from one model to another. The common model is a wonderful
concept we can "discuss" until the sun goes super nova on us.
<js> But you're choosing to
put a bandaid on a patient that has a severed artery and is bleeding to death.
There are lots of common models because there hasn't been a concerted effort
to fix the problem. Just like there are lots of CLIs,
private MIBs, variations of TL1, etc. Translating between these
accomplishes nothing unless we can also address the differences in
semantics. Which is where using XML without addressing object
models will fall short. </js>
regards,
John
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade
Avenue
Colorado
Springs, CO 80903 USA
phone: +1.719.785.0648
FAX: +1.719.785.0644
email:
john.strassner@intelliden.com
-----Original Message-----
From: Durham, David [mailto:david.durham@intel.com]
Sent: Tuesday,
January 07, 2003 10:55 AM
To: Faye Ly; Wijnen, Bert (Bert); Xmlconf
(E-mail)
Subject:
RE: Perspective: XML's ticking time bomb
I think
we need to keep in mind that XML presents a bit of a paradigm shift from what
we have known. Yes, common models are important, but they are almost always
too late for companies and, thus, incompatible with the vast majority of
products when completed. It just takes too long to get them standardized via
the process of compromise, and even longer to get them
right.
What XML
offers is a large set of tools that allow translation between different
vendor's models. These models can be developed independently around a specific
technology, and, if deployed using XML, can still be made to interoperate
where there is commonality.
So your
schema can define "<IntFace> UP </IntFace>" and mine can define
"<Interface> ON </Interface>" and XSLT can be used to translate
between these. Or, better yet, when a standard is completed, vendors can
easily provide translations from it to their existing
models.
IMHO,
this group should focus on determining which XML schema definition language
IETF wgs will use, define the basic reusable data types useful across IETF
wgs, define the operational model for XML transactions, and select a common
transport. Just get the foundation in place & let the models work
themselves out over time in individual wgs and let XSLT be the glue between
the early products and late standards.
-Dave
>
-----Original Message-----
> From: Faye Ly [mailto:faye@pedestalnetworks.com]
> Sent: Sunday, January 05,
2003 8:51 AM
>
To: Wijnen, Bert (Bert); Xmlconf (E-mail)
> Subject: RE: Perspective: XML's ticking time
bomb
>
>
Bert,
>
> That is a
very good article. I admit I went back to this mailing
list's
> archive and got lost in the multiple
mail threads. So what is the
> conclusion on moving forward for this
group?
>
> I think I
tend to agree that XML is a superior language over MIB but
the
> fact that we are missing 'management
object' on many things such as -
>
> Service provisioning/ subscriber
provisioning
>
fault isolation that is transparent to the underlying transport method
>
...
>
> Sort of
similar to the effort of snmpconf (for provisioning only) that
> is currently
missing. I actually think it is in-relevant if we do it
> using XML or
the good old MIB. The important thing is to come up with
> consensus on
the management model. If XML can help with the majority
of
> the people to better understand and
thus expedite the process, then
> let's go with XML. I think this is actually
the time to organize the
> effort around coming up with standards
for:
>
> 1.
provisioning
>
2. fault isolation
> 3. performance monitoring
> 4. othrs such as file management,
upgrade and etc ...
>
> And let each group come up with the management
model first, XML and/or
> MIB later?
>
> What do you think?
>
> -faye
>
> -----Original Message-----
> From: Wijnen, Bert (Bert)
[mailto:bwijnen@lucent.com]
> Sent: Sunday, January 05,
2003 3:51 AM
>
To: Xmlconf (E-mail)
> Subject: Perspective: XML's ticking time
bomb
>
> Here is
another one to take into account:
>
> Perspective: XML's ticking time
bomb
>
>
http://news.com.com/2010-1071-961117.html
>
> It is a few months old... not sure
how I all of a sudden
> ran into it. Oh well...
>
> Bert
>
> --
> 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/>
>
> --
> 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/>
--
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/>