Subject: Re: [NGO] A bigger picture WAS:Re: completed CANMOD agenda

From: <[email-masked]>
Date: Wed, 5 Mar 2008 16:43:43 +0200

Hi,

>-----Original Message-----
>From: ext Andy Bierman [mailto:[email-masked]] 
>Sent: 28.02.2008 15:23
>To: Lahdensivu Mikko (NSN - FI/Tampere)
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: [NGO] A bigger picture WAS:Re: completed CANMOD agenda

>
>So the argument is that the DM readers and writers do not 
>really need to know the language because they will have UI 
>(GUI?) tools to hide the language from them?

They definitely need to know the metamodel and the semantics of the
model, but whether they care about syntax or not is up to them; people
using tools will not need to care, people not using tools will need to
care, but both people can co-operate because they share the same
language, other people accessing directly, other people via tools. At
least I could use either way, depending on how often I would be
accessing the models.

There is no need to have a tool shared by everyone. Some people might
prefer graphical tools, some text based tools, but standards must not
say which tool you should use, or depend on the assumption that everyone
is using same tool. However, it shouldn't be assumed either that no
tools will be implemented, everything is done manually.

>
>We don't standardize screen snapshots in the IETF.

No, of course not, and I have not suggested to standardize models as
screen snapshots, but as XML, which I do not think is specifically a
screen snapshot format (screen snapshots are even less structured than a
typical "plain text" description). I have no problems standardizing
using an XML format, which can be visualized using tools. At least tool
availability for XML is IMHO wider than for ASN.1 (not even speaking of
Yang format).

OTOH you can have a standardized graphical presentation of a model, as
long as the XML, not the graphical presentations themselves, is the
normative form of the model. But this standardization effort of
graphical presentations should not be really in scope of IETF, as it is
sufficient for interoperability that the language for normative
definition of model is defined within IETF. And even if some alternative
presentation forms were standardized by someone, there is no urgency to
do that.

Personally I don't think XML has any worse readability than let's say
SMI, it depends on which format you are used to. In both cases I'd
prefer tools, either specific to the modelling language, or then generic
tools.

And of course even a plain text editor is a tool, without it I would
have difficulties reading "plain text" files :-)

>We need the entire semantics and syntax of a standard 
>expressed in English text.  These are IETF rules, not mine, 
>but I agree with them.  (If I implement the IPFIX model
>5 years from now, will I need the 2008 GUI tool or the 2013 
>GUI tool to view it?  How do I post mailing list comments on 
>video frame 4327 of the YouTube FOOMIB proposal?)

I don't think video is relevant proposal, video (as a way to document a
model) is more close to "plain text" (plain video being a multimedia
version of plain text), rather than structured data, readable by
applications. I see XML directly opposite direction from plain text,
than video. XML content is more structured than plain text, and video
content (esp. YouTube) is even less structured than plain text.

As to which tool to use, it would depend on version of the language, but
in general language should be developed in backward compatible way so in
2013 you could use either tool to view the IPFIX model. If backward
compatibility is not followed, then you would have the same problem even
without tools; which language specification version should you use to
interpret the IPFIX model. And you could always use XML editor (like
with a "plain text" format you would use a plain text editor), if you do
not want to use a language specific tool; this would be similar as
taking a "plain text" editor to view Yang format.

But rearding to expressing syntax in English, if XML cannot be used for
standardization of a syntax in IETF as "not English", then how can
Netconf then use XML schema to define the syntax of the messages? Even
in case of an XML based DML, the semantics would be expressed in English
(in form of documentation fields), at least thus far I haven't seen that
proposals would include XML presentation of data semantics. I don't
understand why models of configuration, in contrast to models of RPC
messages, could not be expressed in XML.

XML is a tradeoff between readability by people and readability by
applications, like Yang format, ASN.1, and people may have different
opinions on the most optimal tradeoff point. But this tradeoff point
should IMHO not be selected per each language separately.

Anyway, I don't see a significant difference, at least for me, between
readability of XML and other structured "plain text", such as Yang. It
more depends on the style which you are used to.

module a {
	class b {
		attribute c {
			type integer;
		}
	}
}

<module id="a">
	<class id="b">
		<attribute id="c">
			<type>integer</type>
		</attribute>
	</class>
</module>

Neither is really _plain_ text, both are structured, the difference is
the style of expressing structures. If both XML and Yang style were new
proposals, not used elsewhere, I'd have nothing against "Yang style"
structuring. However, XML is already widely used, and the structuring of
"Yang style" is not. If every language invents its own structuring
style, then it is actually harder for both the tools and the people to
read all of them.

Regards,

Mikko
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Leif Johansson <[email-masked]>
Date: Wed, 5 Mar 2008 17:11:32 +0100

> the style of expressing structures. If both XML and Yang style were new

One of the points I was trying to make in the OWL-draft is that you don't have 
to choose serializations just because you have chosen a metamodel. Its quite 
likely that there exists a "yang-style" serialization of OWL (or of RDF to be 
precise).

	Cheers Leif

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Mar 2008 08:23:53 -0800

> tools will be implemented, everything is done manually.

I disagree.
Standards-track specifications need to be understandable.
There are no tools needed, other than the ability to read ASCII files.
This debate was already run on the main IETF list, so there is no
reason to redo it here.

XML is not a data modeling language.
It is aggressively hierarchical syntax, devoid of semantics.
There are plenty of 'standard' DMLs which use XML syntax.
(To me that means one should pick a DML according
to their needs, since there is no 1-size-fits-all standard.)

According to the XML 1.0 spec,
XML is designed for use by computer programs, not humans.

http://www.w3.org/TR/REC-xml/#sec-intro

If the designers of XML don't think it is suitable for
use as a documentation language, then why should I?
Ease of use by humans didn't even make their Top 10 list
of design goals, yet to me, it is #1.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 05 Mar 2008 17:47:56 +0100

In YANG you have both a new (in our view) more readable format and an XML based YIN format that 
contains equivalent information and can be translated back an forth. However we believe XML is 
not the best format for humans to read and especially to write, so invented the simpler YANG 
format.

If you think about it there is another MAJOR XML standard that came to exactly the same 
conclusion: raw XML is not nice for humans, and invented a compact notation :-)

Balazs

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 19:30:18 +0200

Hi,

>Sent: 05.03.2008 18:24

>> say which tool you should use, or depend on the assumption that 
>> everyone is using same tool. However, it shouldn't be assumed either 
>> that no tools will be implemented, everything is done manually.
>> 
>
>
>I disagree.
>This debate was already run on the main IETF list, so there is 
>no reason to redo it here.

Yes, specifications need to be understandable, but I do think XML
documents are understandable enough by human readers (without tools
other than text editor), sufficiently so that no tool usage is required.
But what I mean by not assuming that tools won't be implemented is that
we shouldn't optimize only for human reader, but balance between tools
and human readers (and I think XML is IMHO a good starting point for
this balance).

If documenting syntax in XML is somehow fundamentally incompatible with
IETF requirements, then I do not understand how Netconf can, on
standards track, use XML schema to define syntax for the signalling
data. Netconf server would implement both the signalling data and the
configuration data, so why XML can be used to describe syntax of one but
not the other type of data?

>(To me that means one should pick a DML according to their 
>needs, since there is no 1-size-fits-all standard.)
>
>If the designers of XML don't think it is suitable for use as 
>a documentation language, then why should I?
>Ease of use by humans didn't even make their Top 10 list of 
>design goals, yet to me, it is #1.

"6. XML documents should be human-legible and reasonably clear.", or did
you mean something else?

Regards,

Mikko

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Mar 2008 09:32:32 -0800

[email-masked] wrote:
>...

Differences in readability don't show up well in trivial
4 line "hello world" type of examples.  They do show up
in real data models, such as the new IPFIX data model.
Real XML, with namespace prefixes, and character entities,
is not very readable.

The real issue is how well the particular tags within the DML
express the high-level semantics that need to be conveyed to humans.
As a DM reader, I really don't care that much what the XML looks like,
yet that the main goal of some of the proposals.   I want to read
about the RPCs, containers, lists, leafs, and notifications that
the NETCONF application developer can use.

IMO, configuration parameters do not need to be object-oriented.
They aren't implemented that way in NE devices: the CLI isn't OO,
SNMP isn't OO, SYSLOG isn't OO -- none of the data silos that
most network devices contain are not OO.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Mar 2008 09:49:33 -0800

> not the other type of data?

Protocol specifications are a good use-case for XSD.
They only contain PDU exchanges, which are legitimate
XML instance documents.  Usually, only protocol implementers
need to read these XSDs.

Network management data, on the other hand, is used by network operators.
Instead of a full-time engineer dedicated to understanding 1 protocol
spec, there is an IT tech who needs some familiarity with potentially
100s of data model specs.  In this use-case, readability is priority #1.

> "6. XML documents should be human-legible and reasonably clear.", or did

To me, this just means they should use printable characters instead
of binary encoding.  'Easy for a human to understand' is not the same thing.

Andy

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 20:34:43 +0200

Hi,

>Instead of a full-time engineer dedicated to understanding 1 
>protocol spec, there is an IT tech who needs some familiarity 
>with potentially 100s of data model specs.  In this use-case, 
>readability is priority #1.
>

And perhaps in this case the IT tech needs to read some other XML
documents as well, and having familiar syntax of XML would be more
readable than specific syntax of Netconf DML.

Network management data is used by humans and tools, both use cases are
important, the easier it is to implement good tools, the less people
need to care about the syntax of model language (because tools can give
them context-sensitive information about part of the model they operate
on), and XML is not incompatible with IETF understandability criterion.

And at least for me XML is more readable than ASN.1.

>> "6. XML documents should be human-legible and reasonably clear.", or 
>> did you mean something else?
>> 
>
>To me, this just means they should use printable characters 
>instead of binary encoding.  'Easy for a human to understand' 
>is not the same thing.

Why did they just want to use printable characters, instead of intending
it to be easy for humans to read? Let me see, base64 encoded BER encoded
data is also only using printable characters, why on earth did they not
pick that format, much more compact format? IMHO XML design has taken
human understandability into account quite much, but it is true that XML
has had other goals as well, it is a tradeoff between different goals.

Regards,

Mikko