Subject: [netmod] YIN as input

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 07:05:50 -0800

Hi,

Maybe this is out of scope for the standard,
but I want to make sure...

A 'YANG tool' MAY choose to convert YIN to YANG first,
and not process YIN directly as input.  This will
only impact out-of-scope line numbers and other text
in error/warning messages.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2009 16:28:33 +0100

> in error/warning messages.

As far as I am concerned, a YANG parser only needs to be able to parse
YANG modules. Something that can parse YIN modules natively I would
call a YIN parser.

I do not have a definition of "YANG tool" - but I would expect that
such a tool supports and YANG parser (and I would leave it open what
happens if you feed YIN into it ;-).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Mon, 7 Dec 2009 10:11:09 -0500

>in error/warning messages.

Yup, I could make an XSLT script that converts YANG modules to C
code, and it would only handle YIN input.  This is a tools issue.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 08:08:42 -0800

> happens if you feed YIN into it ;-).

I agree with you, but these seems to be some
expectation (by others) that the 2 forms are
conceptually equivalent for all 'YANG RFC' compliant tools.

The filename shows a YANG module extension as (.yang | .yin),
and Balazs has said he wants tools to accept either form.

I agree the standards requirement is that there is a loss-less
mapping between the 2 forms, and the standard does not say
anything about which tools must use which form.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Dec 2009 18:56:48 +0100

> anything about which tools must use which form.

I had some private interaction about this with Martin and I am going
to post a separate last call comment in order to make this clearer.
But give me a few more days of reading time.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 10:17:01 -0800

> But give me a few more days of reading time.

Sure.  We also need to resolve the other WGLC comments:
   - change rules wrt/ revisions
   - filename separator char (. or @ or +)

IMO, there is nothing to test wrt/ YIN compliance except
the translation between YIN and YANG format.  If I
am wrong, please point out the text that defines more
YIN requirements.

A YANG compiler follows the YANG ABNF.  I don't know what
normative syntax a YIN compiler would use.

The YIN to YANG translation is not exactly spelled out either.

Also, I suggest showing a complete example for YIN,
starting from the top-level element:

   <?xml version="1.0" encoding="UTF-8"?>
   <module
      name="acme-foo"
      xmlns="urn:ietf:params:xml:ns:yang:yin:1">
      <namespace uri="urn:ietf:params:xml:ns:yang:acme-foo-DRAFT-00" />
      <prefix value="yang" />
      ...
      ... put the current leaf example here
   </module>

Also, a translator is probably going to want to
declare the same XML prefixes as used in all the import-stmts:
e.g. import ietf-yang-types { prefix inet; }

   <?xml version="1.0" encoding="UTF-8"?>
   <module
      name="acme-bar"
      xmlns="urn:ietf:params:xml:ns:yang:yin:1"
      xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types-DRAFT-05">
     ... module contents
   </module>

This does not have to be done in the top-level element of course.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Dec 2009 21:35:55 +0100 (CET)

> The YIN to YANG translation is not exactly spelled out either.

The idea is that YIN is explained as an alternative *syntax* for
YANG.  For each statement it is described what it looks like in YIN.
We could of course include e.g. a RelaxNG schema for YIN, if the WG
thinks it is necessary.  I don't think it is; I think the current
rules are sufficient. 

Ladislav wrote down the RNG and RNC schemas, using the draft, they are
available from
http://www.yang-central.org/twiki/bin/view/Main/YangTools

>       ... put the current leaf example here

Ok.  I can add that, giving this:

  The following YANG module:
  
    module acme-foo {
        namespace "http://acme.example.com/foo";
        prefix "acfoo";
  
        import my-extensions {
            prefix "myext";
        }
  
        list interface {
            key "name";
            leaf name {
                type string;
            }
  
            leaf mtu {
                type uint32;
                description "The MTU of the interface.";
                myext:c-define "MY_MTU";
            }
        }
    }
  
  where the extension "c-define" is defined in ^extension-example^, is
  translated into the following YIN:
  
    <module name="acme-foo"
            xmlns="urn:ietf:params:xml:ns:yang:yin:1"
            xmlns:acfoo="http://acme.example.com/foo"
            xmlns:myext="http://example.com/my-extensions">
  
      <namespace uri="http://acme.example.com/foo"/>
      <prefix value="acfoo"/>
  
      <import module="my-extensions">
        <prefix value="myext"/>
      </import>
  
      <list name="interface">
        <key value="name"/>
  
        <leaf name="name">
          <type name="string"/>
        </leaf>
        <leaf name="mtu">
          <type name="uint32"/>
          <description>
            <text>The MTU of the interface.</text>
          </description>
          <myext:c-define name="MY_MTU"/>
        </leaf>
      </list>
    </module>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 12:48:53 -0800

> thinks it is necessary.  I don't think it is; I think the current

I do not think the draft defines any formal
mechanisms to support YIN as input.  There is only
a YANG to YIN algorithm defined.  I do not see
a table that translates XML elements and attributes
to YANG keywords and arguments.

IMO, supporting YIN directly as input, without
translating to YANG first, is a tools detail
outside the scope of this document.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Dec 2009 22:05:43 +0100 (CET)

> to YANG keywords and arguments.

In version -04, the algorithmic description was rewritten (by Lada)
to a declarative style.  I think the current text is clear on how a
YIN element is supposed to be interpreted:

  There is a one-to-one correspondence between YANG keywords and YIN
  elements.  The local name of a YIN element is identical to the
  corresponding YANG keyword. [...]

  YIN elements corresponding to the core YANG keywords belong to the
  namespace whose associated URI is
  "urn:ietf:params:xml:ns:yang:yin:1"

> outside the scope of this document.

If we want to talk about conformance for tools, that's a separate
issue.  The rules for what YIN is need to be clear in any case.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Dec 2009 13:33:29 -0800

> issue.  The rules for what YIN is need to be clear in any case.

What about the rules for attributes?
Not every XML attribute translates into a YANG keyword.
But I don't really think the YIN to YANG translation
is too hard to figure out, so I don't have any
edits to offer.

Just change the mappings for descriptive statements
to be all the same (text/true).

Andy