Subject: [apps-discuss] An XML RFC primer?

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Jan 2011 11:57:42 -0800

Hi all,

I've got a project on the go that will result in a few different I-Ds for consideration, one of which contains a specification for a new XML-based reporting format.  Can someone suggest some RFCs that have done a good job of the same sort of thing in the past that I could use as a template for such work, or a BCP or similar?

Thanks,
-MSK

---

From: Tim Bray <[email-masked]>
Date: Mon, 10 Jan 2011 12:23:41 -0800

RFC4287 (Atom) specifies a small XML language and has been quite
well-received.  Also see RFC3479 AKA BCP 70.  -Tim

On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy <[email-masked]> wrote:
> Hi all,
>
>
>
> I’ve got a project on the go that will result in a few different I-Ds for
> consideration, one of which contains a specification for a new XML-based
> reporting format.  Can someone suggest some RFCs that have done a good job
> of the same sort of thing in the past that I could use as a template for
> such work, or a BCP or similar?
>
>
>
> Thanks,
>
> -MSK
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Anthony Bryan <[email-masked]>
Date: Mon, 10 Jan 2011 18:43:30 -0500

> such work, or a BCP or similar?

there's also the slightly newer Metalink, RFC 5854, based heavily off of Atom.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 11 Jan 2011 09:33:48 +0900

On 2011/01/11 5:23, Tim Bray wrote:
> well-received.

Yes. But please note that some special requirements on namespace 
declarations are highly non-standard and not recemmended for imitation.

> Also see RFC3479 AKA BCP 70.  -Tim

That one is indeed very well worth reading.

Regards,    Martin.

> On Mon, Jan 10, 2011 at 11:57 AM, Murray S. Kucherawy<[email-masked]>  wrote:
>> Hi all,
>>
>>
>>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Tim Bray <[email-masked]>
Date: Mon, 10 Jan 2011 16:38:36 -0800

What are the non-standard namespace practices in 4287?  -Tim

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 11 Jan 2011 10:19:28 +0900

For a very long time during the discussions in the Atom WG, there was a 
requirement to put the namespace declaration for the HTML namespace on 
the div element that encloses XHTML content. Going back now to the spec, 
I see that that requirement/wart is gone (see 
http://tools.ietf.org/html/rfc4287#section-3.1.1.3). Congratulations to 
whomever got the WG to get away from this (was that you?).

I herewith gladly retract my concern re. Atom. It's good to learn that 
things are better than one has thought, even if it takes a long time.

Regards,   Martin.

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Jan 2011 11:27:50 +0000

On Mon, 10 Jan 2011, Tim Bray wrote:

> Also see RFC3479 AKA BCP 70.

I think you mean RFC 3470.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Jan 2011 07:28:53 -0800

Oops yep good catch.
-Tim

On Jan 11, 2011 3:27 AM, "Tony Finch" <[email-masked]> wrote:

Tony.

---

From: "t.petch" <[email-masked]>
Date: Tue, 11 Jan 2011 18:08:37 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 10, 2011 8:57 PM

I've got a project on the go that will result in a few different I-Ds for
consideration, one of which contains a specification for a new XML-based
reporting format.  Can someone suggest some RFCs that have done a good job of
the same sort of thing in the past that I could use as a template for such work,
or a BCP or similar?

<tp>

Netconf chose XML and XSD, and probably wishes it hadn't.  I had a quick scan of
archives and cannot find any decent summary of just why it doesn't work; Randy
Presuhn is always the most articulate as to just why XML gets it wrong, its lack
of coherent intellectual underpinnings.  OK, Netconf has a more challenging
objective, of replacing aspects of SMI and SNMP but even so, some at least of
the problems are generic, such as
 - lack of proper typing
 - naming and namespaces (eg the no namespace, null namespace, ...)
 - impossibility of validating documents with XSD (possible with DSDL).

I did a survey of many (most?) IETF XML RFC/I-D before we started, and saw a lot
of options with no guidance as to which way to go.  (I found some documents that
were plain wrong).  I raised this lack of guidance on the IETF list but got no
traction.

Netconf did take advice from the XML Directorate, and they were plain wrong, in
one key regard, which has turned out to be an issue that has taken years so far,
and as yet is unresolved (the question they failed to answer correctly was what
is and is not valid XML? the consequence is an inability to parse XML documents
transported by Netconf as currently specified).

So, if there anything better, with tools available, I would recommend it

Tom Petch
</tp>

Thanks,
-MSK

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Jan 2011 11:46:31 -0800

>  - impossibility of validating documents with XSD (possible with DSDL).

The general lousiness of XSD is now well-known.  Atom was very happy
with RNG, but ymmv.

> transported by Netconf as currently specified).

Huh?  Formally, "valid" means "has a DTD and conforms to it" but
almost nobody uses DTDs any more.  Whether something is or is not XML
is not in any doubt either de jure or de facto, we have good
interoperability among parsers these days.  If Netconf XML can't be
parsed, the specification must have some awful problems.

I've certainly seen some lousy XML-based protocols here and there, but
this the first instance of "inability to parse" I've run across.

 -Tim

---

From: Tim Bray <[email-masked]>
Date: Tue, 11 Jan 2011 11:47:27 -0800

Oh, and others have also found this slide-set, from a talk I gave at
the Vancouver IETF, useful:
http://www.ietf.org/proceedings/70/slides/xmltut-0.pdf  -Tim

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Jan 2011 22:17:24 +0100

Hi Tom,

> the problems are generic, such as

In fact YANG helps a lot, but yes, types like IP addresses are still not built in.

> - naming and namespaces (eg the no namespace, null namespace, ...)

Well, in hindsight, XML namespaces perhaps could have been done in a better way - James Clark has an interesting account on it in his blog - but namespaces as such are indispensible for NETCONF data modeling. For example, JSON has no namespaces.

> - impossibility of validating documents with XSD (possible with DSDL).

I am not a fan of XSD (as you know) but this statement may be too strong. In the particular case of RFC 4741, the problem is more in the design of the XSD schema than in XSD as such.

> Netconf did take advice from the XML Directorate, and they were plain wrong, in

It seems it was sufficient to carefully read the XML spec.
 
> transported by Netconf as currently specified).

This has been recently resolved in draft-ietf-netconf-rfc4742bis-05.
 
> So, if there anything better, with tools available, I would recommend it

My observation is that quite often problems have been caused by how people (mis)use XML rather than by XML itself.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: "t.petch" <[email-masked]>
Date: Wed, 12 Jan 2011 10:15:22 +0100

----- Original Message -----
From: "Tim Bray" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 11, 2011 8:47 PM
Subject: Re: [apps-discuss] An XML RFC primer?

<tp>

Yes, I endorse that.
 (especially where it says 'Use Plain Text If: ... you possibly can')

I also found a series of 11 .pdf about XML Best Practices most
helpful in identifying the choices a user of XML has to make, and
some of the consequences.  It is these choices I would have liked
the IETF to be more pro-active about, back in 2006, but, as I said,
there was no support for that.

Tom Petch
</tp>

---

From: "t.petch" <[email-masked]>
Date: Wed, 12 Jan 2011 10:19:49 +0100

----- Original Message -----
From: "Tim Bray" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Murray S. Kucherawy" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 11, 2011 8:46 PM

<tp>
I was not clear enough.  It is the ability to parse the Netconf
datastream into XML documents that is the problem with
Netconf as currently specified, and which has caused much
grief for several years.  As Lada has said, there is an I-D
which is likely to fix this (but whose progress is tortuous).

Tom Petch

</tp>

 -Tim

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Jan 2011 13:08:03 +0100

> which is likely to fix this (but whose progress is tortuous).

Simply put, somebody was able to convince the WG that the string
"]]>]]>" cannot appear ANYWHERE in a valid XML document, so this string
was used as the end-of-message marker. It was not technically difficult
to fix this blunder, the biggest problem was backward compatibility with
devices that already use the broken framing.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C