On 02/08/2012, at 1:11 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
I think anyone with intimate experience of the Web Services standards
I do, unfortunately.
Specifically: contributor to SOAP, WS-Addressing, WS-Policy, MTOM, lead editor
of the WS-I Basic Profile, etc. (ad nauseum).
experiment (trying to use XML as if it was a Turing machine) would have
extreme doubts about any proposal to impose such a requirement.
It was not for no reason that many people came to refer to the Web
Services family of standards as "WS-splat". The words "small" and
"xml schema" don't really belong together,
+1
XML Schema is grossly over-engineered for its purpose; being the subject of
requirements from not only the document markup field, but also databases and
object models, it's a twisted monstrosity that tries to do many things, and
fails at most.
Specifically, it's very common for people to try to use schema to inform
"binding" tools into specific languages. However, the underlying metamodel of
XML, the Infoset, is both complex and a poor fit for most languages, so
bindings take "shortcuts" and expose a profile of XML's range of expression,
encouraging some patterns of use, while discouraging (or disallowing) others.
Since the bindings often make different decisions (based upon the language of
use), interoperability is difficult (sometimes, impossible).
Furthermore, designing a schema that is extensible is incredibly convoluted in
XML Schema 1.0. Schema 1.1 was designed to address this failure, but it hasn't
been broadly adopted; most people I know in the field consider it a failure.
What surprises me and many others is that people are still using it and
promoting it, when it's well-understood by almost EVERYONE who was involved in
using XML for protocols in the past ten years agrees that it's a mistake.
Cheers,
Regards
Brian Carpenter
On 02/08/2012 18:12, Robert Raszuk wrote:
Hi Dan,
We should be talking
nowadays about a toolset rather than one tool that fits all.
Just to clarify what I asked about .. I am not looking for a single tool
or single protocol to be used to configure everything.
I am asking for small building block like xml schema (or something
similar) to be part of each new IETF proposal or protocol change. IMHO
only that can allow any further more fancy abstractions and tools to be
build and used in practice.
Best regards,
R.
Hi,
The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
concerning the revision of RFC1052 and discussing a new architecture for
management protocols.
My personal take is that no one protocol, or one data modeling language
can match the operational requirements to configure and manage the wide
and wider range of hosts, routers and other network devices that are
used to implement IP networks and protocols. We should be talking
nowadays about a toolset rather than one tool that fits all. However,
this is a discussion that just starts.
Regards,
Dan
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of
Robert Raszuk
Sent: Thursday, August 02, 2012 7:25 PM
Cc: ietf(_at_)ietf(_dot_)org
Subject: Basic ietf process question ...
All,
IETF documents have number of mandatory sections .. IANA Actions,
Security Considerations, Refs, etc ...
Does anyone have a good reason why any new protocol definition or
enhancement does not have a build in mandatory "XML schema" section
which would allow to actually use such standards based enhancement in
vendor agnostic way ?
There is a lot of talk about reinventing APIs, building network wide
OS
platform, delivering SDNs (whatever it means at any point of time for
one) ... but how about we start with something very basic yet IMHO
necessary to slowly begin thinking of network as one plane.
I understand that historically we had/still have SNMP however I have
never seen this being mandatory section of any standards track
document.
Usually SNMP comes 5 years behind (if at all) making it obsolete by
design.
NETCONF is great and very flexible communication channel for
provisioning. However it is sufficient to just look at number of ops
lists to see that those who tried to use it quickly abandoned their
efforts due to complete lack of XML schema from each vendor they
happen
to use or complete mismatch of vendor to vendor XML interpretation.
And while perhaps this is obvious I do not think that any new single
effort will address this. This has to be an atomic and integral part
of
each WG's document.
Looking forward for insightful comments ...
Best,
R.
--
Mark Nottingham
http://www.mnot.net/