Hi,
Agreed - XSD is not informal like pseudo-code (which is an eye
of the beholder term).
XSD is a formal language, just like the ASN.1 we all darn well
depend on in MIBs (which ASN.1 _does_ override any error in
descriptive text in the MIB body or preface - an ASN.1 type
definition is a hard mathematical fact).
right & that's what I would've thought the messages defined in netconf
should be as well.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Hector Trevino
Sent: Friday, March 18, 2005 3:41 PM
To: Andy Bierman
Cc: sberl@cisco.com; 'Wes Hardaker'; 'Andy Bierman';
netconf@ops.ietf.org
Subject: Re: Proposed Resolution to PROT I-D Issues List
in-line
Hector
Andy Bierman wrote:
Steven Berl (sberl) wrote:
<snip>
----------------------
New text for the beginning of appendix B:
The following XML schema is for informational purposes. It has
reviewed but there is no guarantee that the schema exactly matches
the definitions defined in the protocol description above.
Implementations MUST NOT assume that an incoming message is free
from malicious intent because it has been successfully verified
against this schema.
I think we should make the text normative and the XSD as correct as
possible,
but not intended to override the text. The exact standard netconf XSD
that
an agent should accept is different depending on the exact set of
capability
values supported by that agent for a particular session.
The XSD represents a superset of all base + standard capability variants.
I think this is good enough.
Why couldn't the operation defintions in the XSDs be normative as well?
Seems this is a way to help with interoperability.
I agree that "The XSD represents a superset of all base + standard
capability variants" and it is an implementation decision as to what
capabilities are supported/implemented but the definitions themselves
should be normative. I guess I don't understand the objection to making
the schemas normative.
Andy
Are you saying that we have a formal language description of the
syntax of
the protocol messages, but that is there just for information? The real
definition of the syntax is in the narrative text? It seems to me
that this
is kind of backwards. Is this the way that MIBs work? Is the ASN.1 there
just for information and the real description of the MIB is in the
text? The
normative reference for message syntax should be the schema, and the
text
should be there to describe the schema, and to explain things that
are not
expressed in the schema such as the sequence of messages, or additional
constrains.
-steve
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>