Subject: [Ecrit] Procedural Questions to the Group

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 8 Sep 2011 20:40:52 +0300

Hi all, 

During the discussions of the additional data specification we had
noticed a couple of issues that are worth bringing to the attention of
the group. The topic concerns schema specifications with the work around
the additional data work. 

In various IETF specifications that make use of XML one can find either
an XML schema or a Relax NG schema. 

Strictly speaking a schema is NOT needed. There is, however, the believe
that it adds some value although I believe it actually causes more
confusion than it helps but we can discuss this. 

In any case, we have used Relax NG schema in many ECRIT specifications
because we thought it provides better extensiblity properties but we
were completely wrong. When you extend a Relax NG or a XML schema then
the value on gets from validation goes to zero. 

Now, in the additional data specification we have the issue that we
fold-in content from various sources, including a Vcard specification
(which, if used as currently specified, does not even use an XML
encoding).  

Furthermore, XML has gotten less favorable over time (because it is very
verbose and XML digital signatures are painful) and they have decided to
switch to something new, namely JSON. JSON is less verbose and the
preferred choice in the Web development community. 

The question for me is whether we should consider a switch to JSON
because the question about the schema then becomes irrelevant or should
we stay with XML and make a decision regarding the schema and a way
forward with the additional data specification. 

I personally believe that JSON would be a better choice. 

Even if we stay with XML then I would prefer to omit the schema
altogether and instead work on reference implementations for tools that
allow us to create compliant XML instance documents and to verify those.

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Sep 2011 08:08:08 +0800

Having both written and used specifications that use schemas of various forms, there are a few key considerations:

 - A schema provides a formal definition of syntax.  When correctly specified, this is a great aid to interoperability.  Often, text descriptions of parameters miss key points (cardinality, syntax specifics, ordering concerns).  Schemas help eliminate a lot of ambiguities.  Having ongoing experience with the most widely used schema language (ASN.1), I'd have to say that it is an invaluable tool in defining complex protocols.

 - A good schema is difficult to specify.  But that problem doesn't go away when you remove the schema - it only moves the problem to the text.  Usually, that biases the specification toward ambiguity (worse interoperability) over specificity (worse forward compatibility).

 - Forward compatibility is the single hardest thing to get right in any protocol.  With all the work on extension support in schemas, it's telling that the state of the art remains an approximation of type-length-value.

- JSON simplifies the problem of definition by limiting the choices available.  Its popularity is no mere fad - it beats XML in the same way that XML beat SGML.  However, JSON doesn't do anything to address the central concern of rigor of specification.  The fact that JSON schema [1] exists would indicate that there is at least some desire to make JSON-based specifications more rigorous.

- With respect to implementation, tools support for a schema is extremely important.  A schema can make implementation easier.  Relax NG has fewer good tools, or the tools aren't as good as those for XML schemas.  Or at least that is true for the languages I am most familiar with.  This is only a secondary concern, because schemas can be constructed as a programming exercise, though that runs the risk of implementation divergence.

I have to agree that a schema is a poor substitute for actual interoperability testing.  On the other hand, rejecting the idea outright is not necessarily an easier path to follow.

--Martin

[1] http://tools.ietf.org/html/draft-zyp-json-schema-03

On 2011-09-09 at 03:40:52, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> the group. The topic concerns schema specifications with the work 
> around the additional data work.
> 
> In various IETF specifications that make use of XML one can find 
> either an XML schema or a Relax NG schema.
> 
> Strictly speaking a schema is NOT needed. There is, however, the 
> believe that it adds some value although I believe it actually causes 
> more confusion than it helps but we can discuss this.
> 
> Furthermore, XML has gotten less favorable over time (because it is 
> very verbose and XML digital signatures are painful) and they have 
> decided to switch to something new, namely JSON. JSON is less verbose 
> and the preferred choice in the Web development community.
> 
> because the question about the schema then becomes irrelevant or 
> should we stay with XML and make a decision regarding the schema and a 
> way forward with the additional data specification.
> 
> 
> altogether and instead work on reference implementations for tools 
> that allow us to create compliant XML instance documents and to verify 
> those.
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 9 Sep 2011 10:02:46 +0300

Hi Martin, 

there are two problems with the schema: 

* You have to provide a verbal description anyway. Those who read specifications do not only want to look at a bare schema; they want to read some human readable text. So, you are essentially describing semantic of the protocol twice (once verbally and then again via the XML schema). I have seen this many, many times in specifications. Everything is at least described twice - and often not in sync. 

* The schema lacks expressiveness so that you have to rely on a verbal description anyway. If if you could describe everything in a schema for a given protocol the result would look horrible. Particularly if you add the proper extension points schemas tend to become unreadable. 

The schema provides little help in verifying whether a given XML instance document is correct (valid) because of the extension points and because of the additional constraints only described in the text, i.e. constraints not covered in the schema. The latter issue is particularly problematic since we are often describing complex protocols. 

I raised the JSON issue particularly because of the size aspects. With XML we have gone quite far to convey a few bits - think about location conveyance, for example. We had encountered that problem recently with CAP (for the data only call in ECRIT) but also in ATOCA with alerts. 

Why don't we go a route that really helps implementers rather than doing something just half-way?

Ciao
Hannes

On Sep 9, 2011, at 3:08 AM, Thomson, Martin wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 9 Sep 2011 15:19:28 +0800

Schemas define syntax only.  That does allow you to concentrate your efforts in prose on the important stuff: semantics.

Doubling up is inevitable, but not necessary.  TLS, for instance, does a decent job of avoiding discussion on cardinality, number of bits, etc...  It uses a schema language of its own devising.

I use XML schema to validate messages.  It's a little clunky because you have to use modified schemas so that the extension points don't end up being "accept junk" points, but it can be done (and I'm happy to share the meagre tools I use for this purpose if that helps anyone else).

Don't misunderstand me about JSON.  It think that it's a great idea.  But I don't think that it solves any of the fundamental problems.  Nor does it really save many bytes, if that's what you care about.

--Martin

On 2011-09-09 at 17:02:46, Hannes Tschofenig wrote:
> * You have to provide a verbal description anyway. Those who read 
> specifications do not only want to look at a bare schema; they want to 
> read some human readable text. So, you are essentially describing 
> semantic of the protocol twice (once verbally and then again via the 
> XML schema). I have seen this many, many times in specifications.
> Everything is at least described twice - and often not in sync.
> 
> * The schema lacks expressiveness so that you have to rely on a verbal 
> description anyway. If if you could describe everything in a schema 
> for a given protocol the result would look horrible. Particularly if 
> you add the proper extension points schemas tend to become unreadable.
> 
> The schema provides little help in verifying whether a given XML 
> instance document is correct (valid) because of the extension points 
> and because of the additional constraints only described in the text, 
> i.e. constraints not covered in the schema. The latter issue is 
> particularly problematic since we are often describing complex 
> protocols.
> 
> I raised the JSON issue particularly because of the size aspects. With 
> XML we have gone quite far to convey a few bits - think about location 
> conveyance, for example. We had encountered that problem recently with 
> CAP (for the data only call in ECRIT) but also in ATOCA with alerts.
> 
> > Having both written and used specifications that use schemas of
> various forms, there are a few key considerations:
> >
> > - A schema provides a formal definition of syntax.  When correctly
> specified, this is a great aid to interoperability.  Often, text 
> descriptions of parameters miss key points (cardinality, syntax 
> specifics, ordering concerns).  Schemas help eliminate a lot of 
> ambiguities.  Having ongoing experience with the most widely used 
> schema language (ASN.1), I'd have to say that it is an invaluable tool 
> in defining complex protocols.
> >
> > - A good schema is difficult to specify.  But that problem doesn't 
> > go
> away when you remove the schema - it only moves the problem to the 
> text.  Usually, that biases the specification toward ambiguity (worse
> interoperability) over specificity (worse forward compatibility).
> >
> > - Forward compatibility is the single hardest thing to get right in
> any protocol.  With all the work on extension support in schemas, it's 
> telling that the state of the art remains an approximation of type- 
> length-value.
> >
> > - JSON simplifies the problem of definition by limiting the choices
> available.  Its popularity is no mere fad - it beats XML in the same 
> way that XML beat SGML.  However, JSON doesn't do anything to address 
> the central concern of rigor of specification.  The fact that JSON 
> schema [1] exists would indicate that there is at least some desire to 
> make JSON-based specifications more rigorous.
> >
> > - With respect to implementation, tools support for a schema is
> extremely important.  A schema can make implementation easier.  Relax 
> NG has fewer good tools, or the tools aren't as good as those for XML 
> schemas.  Or at least that is true for the languages I am most 
> familiar with.  This is only a secondary concern, because schemas can 
> be constructed as a programming exercise, though that runs the risk of 
> implementation divergence.
> >
> > I have to agree that a schema is a poor substitute for actual
> interoperability testing.  On the other hand, rejecting the idea 
> outright is not necessarily an easier path to follow.
> >
> > --Martin
> >
> >> noticed a couple of issues that are worth bringing to the attention 
> >> of the group. The topic concerns schema specifications with the 
> >> work around the additional data work.
> >>
> >> In any case, we have used Relax NG schema in many ECRIT 
> >> specifications because we thought it provides better extensiblity 
> >> properties but we were completely wrong. When you extend a Relax NG 
> >> or a XML schema then the value on gets from validation goes to zero.
> >>
> >> should we stay with XML and make a decision regarding the schema 
> >> and a way forward with the additional data specification.
> >>
> >>
> >> that allow us to create compliant XML instance documents and to 
> >> verify those.
> >> Ciao
> >> Hannes
> >>
> >
> >
> >