Subject: [Tools-team] XML validity when submitting

From: Bill Fenner <[email-masked]>
Date: Thu, 18 Nov 2004 17:30:40 -0500

A couple of people have tried my xxe plugin and found that it wouldn't
open files that xml2rfc processed just fine - in these cases it's that
xml2rfc doesn't validate the XML and has a lenient parser.

This raises a problem, in that we don't really want to have invalid
XML in the repository (right?) but we also don't want people to have
the "but it works fine on my system, it only barfs when I upload it!"
problem.

Any thoughts?

  Bill

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 18 Nov 2004 16:11:03 -0700 (MST)

On Thu, 18 Nov 2004, Bill Fenner wrote:

> XML in the repository (right?)

Correct.

> but we also don't want people to have the "but it works fine on my 
> system, it only barfs when I upload it!" problem.

I am not sure what it would take to (a) convince Marshall that xml2rfc 
support of XML needs to be fixed and (b) fix it. Marshall has stated 
that the XML parser inside the xml2rfc Tcl script is old/crufty; he 
was understandibly reluctant to change it. I do not know whether 
better parsers exist for Tcl.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 18 Nov 2004 18:21:13 -0500

Bill Fenner <[email-masked]> writes:

> the "but it works fine on my system, it only barfs when I upload
> it!"  problem.

If the server uses the same software that most people would use for
processing XML, maybe the problem would not be very severe?

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 18 Nov 2004 17:05:52 -0700 (MST)

> processing XML, maybe the problem would not be very severe?

Let me try to explain: xml2rfc software does not catch some XML bugs. 
Other tools that will be written to process posted XML sources (for 
reasons other than draft formatting) would have problem dealing with 
posted XML sources submitted by authors that use nothing but xml2rfc.

In short, like Bill said, we should not post invalid XML.

If we use an XML validator to reject invalid XML sources when posting 
drafts (after preprocessing them to resolve include PIs), some (many?) 
authors would have a difficult time fixing their XML sources because 
they do not use anything but xml2rfc, and xml2rfc does not complain.

Does this clarify?

Thanks,

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 18 Nov 2004 19:21:37 -0500

> Let me try to explain: xml2rfc software does not catch some XML bugs.

I believe I understand that.  Why not just run xml2rfc, the same
software as most authors would be using to deal with XML, on the
server and accept any XML that xml2rfc likes, whether another
validator likes it or not?  What would be the danger in admitting a
syntax error that xml2rfc happily ignores?

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 18 Nov 2004 17:35:11 -0700 (MST)

> syntax error that xml2rfc happily ignores?

Because there will be other tools trying to parse posted XML and they 
cannot ignore broken XML. In other words, while xml2rfc might be the 
only "producer" of XML, there will be many more consumers.

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 18 Nov 2004 19:35:01 -0500

>processing XML, maybe the problem would not be very severe?

I'm concerned about the people who use vi or emacs for processing
XML, generate something that xml2rfc is capable of rendering but
is not actually XML, and then get their draft submission rejected.

(Aaron from the RFC-Editor found that one out of the 3 files he
tried was malformed; Pekka Savola emailed me and said that he
always just puts a bare "&" in the text when he wants an "&" so
presumably any of his drafts that contains an "&" are malformed.)

  Bill

---

From: Larry Masinter <[email-masked]>
Date: Thu, 18 Nov 2004 17:26:31 -0800

> is not actually XML, and then get their draft submission rejected.

I'm not. Geez, we have standards for a purpose. The posted Internet
Drafts in XML actually need to be interoperable with XML processing
tools -- beyond formatting by xml2rfc -- if we're going to get
any benefit out of them being posted in XML.

I mean, "XML" isn't just some buzz-word, there is actually a standard.
And, interoperability is defined by the standard, and not what
one particular popular tool happens to evaluate.

And I have to give this rant to people who actually are supposed
to be familiar with "standards" and why anyone gives a hoot
about what they say.

Why don't we just skip the IETF and tell people to reverse-engineer
whatever it is that Cxxxx or Mxxxxxx ship?

> presumably any of his drafts that contains an "&" are malformed.)

So he's wrong and he can put his lazy fingers into gear and
type &amp; when his first submitted XML internet draft gets
rejected.

Larry
-- 
http://larry.masinter.net

---

From: stanislav shalunov <[email-masked]>
Date: 18 Nov 2004 20:39:18 -0500

Alex Rousskov <[email-masked]> writes:

> Because there will be other tools trying to parse posted XML and
> they cannot ignore broken XML. In other words, while xml2rfc might
> be the only "producer" of XML, there will be many more consumers.

I thought xml2rfc was a consumer of XML customarily (and a producer of
RFC-formatted plain text).

So, an automated extraction of something like an author name from XML
might barf.  So what?  XML isn't required, so having *some* form of
source code (indeed, the only existing form of source code for the
I-D) is clearly better than none.  If the tool starts complaining
about optional XML, I would bet most people would simply not upload
it.

I must be missing something.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 18 Nov 2004 20:00:27 -0700 (MST)

> RFC-formatted plain text).

Yes, that's why I surrounded "producer" in quotes. By accepting 
invalid XML, xml2rfc effectively produces invalid XML as far as IETF 
infrastructure is concerned. It is the author who is the actual 
producer here, of course, but most authors do not care about XML 
validity (as long as xml2rfc works). The tools do.

> So, an automated extraction of something like an author name from 
> XML might barf.  So what?  XML isn't required, so having *some* form 
> of source code (indeed, the only existing form of source code for 
> the I-D) is clearly better than none.

I think it would be a serious design mistake to accept invalid XML as 
a significant part of IETF infrastructure. I do not think that broken 
XML is better than none. If you do not see that as a problem, I do not 
think I can convince you otherwise (and you would not be alone, since 
many IETFers believe in "garbage in, goodness out" approach to 
interoperability).

> If the tool starts complaining about optional XML, I would bet most 
> people would simply not upload it.

Complaining about and rejecting invalid XML would be much better than 
silently accepting it. I will add the corresponding note to the ID 
Submission draft. I do not think it explicitly mentions XML validity, 
and it should.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 18 Nov 2004 20:07:06 -0700 (MST)

On Thu, 18 Nov 2004, Bill Fenner wrote:

> XML, generate something that xml2rfc is capable of rendering but is 
> not actually XML, and then get their draft submission rejected.

I am even more concerned that ID Submission tool implementation will 
not check for XML validity and accept invalid XML, forcing all other 
tools to deal with it.

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 19 Nov 2004 00:03:10 -0500

> many IETFers believe in "garbage in, goodness out" approach to

I'm not sure this is a case of GIGO, whatever the second G stands
for.  (In any case, personally I have reservations even about the
BLIWYASIWYS motto [be lenient...].)

> Complaining about and rejecting invalid XML would be much better
> than silently accepting it.

Are you saying that having imperfect XML that still works with xml2rfc
would have negative utility?  Or is ``silently'' the operative word?
I would have no problem with doing a real XML validation and issuing
warnings, but turning the warnings into fatal errors would simply
train people not to submit XML to the excessively fussy -- for no
explained reason -- tool.

Is having the source desirable or not?  If it were a C program source,
would you prefer to only have the executable without the source if the
source fails lint but compiles without problems?

> I will add the corresponding note to the ID Submission draft.  I do
> not think it explicitly mentions XML validity, and it should.

It should check PDF validity then, as well.  (I think both are about
equally silly.)

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

"You wake me up early in the morning to tell me I am right?  Please
wait until I am wrong."	-- John von Neumann, on being phoned at 10 a.m.

---

From: stanislav shalunov <[email-masked]>
Date: 19 Nov 2004 00:12:14 -0500

> I mean, "XML" isn't just some buzz-word, there is actually a standard.

Many things have standards and deviations from standards.  I don't
delete from my system's /usr/src all C source code that is not real
C99.  I'd prefer it to be perfect, sure, but even imperfect source
code is better than none.

The right question isn't whether invalid XML is bad (it clearly is),
but what would a user -- who is not required to submit XML -- do if
the tool is fussy about something in his XML.

This message is designed to be viewed with 0.06479891g of NaCl.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 19 Nov 2004 11:12:19 -0700

> source fails lint but compiles without problems?

I believe you are missing my point. You keep thinking of invalid XML  
sources as equivalent to C sources
that produce compiler warnings. They are not for two reasons:

	(a) invalid XML sources will prevent many (most?) XML tools from  
extracting _any_ data from them -- many XML parsers used by many tools  
simply fail on invalid XML, by design (C sources with warnings do not  
prevent compilers from producing machine code)

	(b) XML sources are used for more than producing draft formats (C sources  
are usually not used for anything other than compilation of executables)

In other words, for most practical purposes, invalid XML is equivalent to  
a proprietary, unpublished format. Or, if you insist, a broken C code that  
only "works" with one compiler.

> It should check PDF validity then, as well.  (I think both are about

A PDF draft is an IETF loophole, exception to accept complex drawings.
IMO, long term, PDF drafts should either be validated or banned (in favor  
of better formats that render complex drawings).

Alex.

---

From: stanislav shalunov <[email-masked]>
Date: 19 Nov 2004 13:22:42 -0500

"Alex Rousskov" <[email-masked]> writes:

> In other words, for most practical purposes, invalid XML is
> equivalent to a proprietary, unpublished format.  Or, if you insist,
> a broken C code that only "works" with one compiler.

Many C compiler warnings mean that another compiler will or could
produce executable that works differently from the one compiler the
code works with correctly.  So the analogy stands.

> A PDF draft is an IETF loophole, exception to accept complex
> drawings.  IMO, long term, PDF drafts should either be validated or
> banned (in favor of better formats that render complex drawings).

The Tools team is not the place to make these decisions.  (In
addition, the incentive to accept imperfect XML is also greater than
the incentive to accept imperfect PDF: if PDF is rejected and the
author chooses not to publish PDF, the author's communication goals
will suffer; if XML is rejected and the author chooses not to publish
XML, the author does not suffer in any way; only the RFC editor and
whoever is interested in source-level diffs would.)

Al your Qaeda are belong to US.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 19 Nov 2004 13:27:59 -0700

On Fri, 2004/11/19 (MST), <[email-masked]> wrote:

> The Tools team is not the place to make these decisions.

True. And I am not suggesting that we pretend we can make any decisions.  
We can only suggest "designs" or generate "requirements". One of the  
proposed requirements could be that invalid XML is not accepted.

> if XML is rejected and the author chooses not to publish
> whoever is interested in source-level diffs would.

Here we disagree. I think that there will be less long-term suffering  
overall if there is no invalid XML in draft IETF repositories (compared to  
a situation where many archived XML sources are invalid).

Alex.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 19 Nov 2004 13:37:05 -0800

> IMO, long term, PDF drafts should either be validated or 

There aren't too many .pdf internet drafts. About half of the
ones available are also submitted in .ps.
I think it would be useful to validate PDF documents,
not just that they are valid "PDF", but also whether they
meet a stricter profile, e.g., PDF-Archive,  http://www.aiim.org/pdf_a.

What other formats would IETF allow for complex drawings? SVG and
PNG? Perhaps inside 'artwork' tags in xml?

As far as XML validation:

> It would be a better option for IETF, of course. However, Marshall does  
> not work for us and may not want to spend his free time modifying the  
> xml2rfc-embedded XML parser because he had more than enough troubles with

> it already. Perhaps, if we have strong consensus that xml2rfc must only  
> accept valid XML, IETF can pay Marshall or his helper to do the work?

Adding a pre-processing validity checker doesn't require any
work from Marshall at all.  It could be a completely separate
step.

Larry

---

From: stanislav shalunov <[email-masked]>
Date: 19 Nov 2004 17:29:14 -0500

"Alex Rousskov" <[email-masked]> writes:

> overall if there is no invalid XML in draft IETF repositories
> (compared to  a situation where many archived XML sources are invalid).

I think we agree that some source XML files that the authors use will
be valid and some will be invalid.  We both agree that having valid
XML is preferable to not having it.  So the question is about the
invalid XML files.

Would it be fair to say that you frame the choice as follows: invalid
XML or valid XML?

I see the choice differently: invalid XML (that still works with
xml2rfc) or no XML.

If we're choosing between valid and invalid XML, the answer is very
clear.  To me, the answer to the question of invalid XML vs no XML is
equally clear (some form of source code is better than none).  The
users of XML in the repository (including the RFC editor) will not be
harmed by the presence of invalid XML, because anyone can always run a
validator and simply not use the XML file if it's invalid, but no such
local choice is possible when there's no XML.

The realistic options are:

1. Leave XML optional and accept any XML that works with xml2rfc;

2. Require XML and only accept valid XML.

The choice of the first option can be complemented by working with
Marshall and the xml2rfc community to make the set
(accepted_by_xml2rfc - valid) smaller or even empty.

I don't believe that the Tools team has the mandate to choose the
second option.

This message is designed to be viewed upside down.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 19 Nov 2004 16:35:12 -0700

On Fri, 2004/11/19 (MST), <[email-masked]> wrote:

> There aren't too many .pdf internet drafts.

True. That is, in part, why I do not care much what we do with them.

> meet a stricter profile, e.g., PDF-Archive,  http://www.aiim.org/pdf_a.

Agreed, but what can an author of a PDF draft do if their PDF draft does  
not meat PDF-Archive requirements?

> PNG? Perhaps inside 'artwork' tags in xml?

Sure, but since there are so few PDF drafts, I do not think it is a  
problem worth solving now.

>> xml2rfc-embedded XML parser because he had more than enough troubles  
>> with it already. Perhaps, if we have strong consensus that xml2rfc must  
>> only

The pre-processing validity checker would be least annoying and most  
useful if it is a part of xml2rfc. If xml2rfc accepts invalid XML then we  
would have hard time convincing Stas (for example) that the ID Submission  
Toolset should reject invalid XML.

Alex.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 19 Nov 2004 16:49:58 -0700

On Fri, 2004/11/19 (MST), <[email-masked]> wrote:

> The users of XML in the repository (including the RFC editor) will not be
> validator and simply not use the XML file if it's invalid

What usually happens though, is that code gets written to accommodate  
invalid XML and, eventually, all IETF tools would have to do it, because  
some IETF tools do it. Web browsers accepting invalid HTML is a good  
example why this is likely to happen and why this is bad. Note that W3C  
specs require browsers to reject invalid XHTML (I know my browser does).  
They have learned their "GIGO" lesson the hard way.

Note that RFC Editor is free to ask Authors for [invalid] XML sources,  
just like they are doing today. There are a lot more draft versions than  
RFCs, so I would give priority to the common case.

> 2. Require XML and only accept valid XML.

   3. Leave XML optional and accept only valid XML.

   4. Leave XML optional and archive invalid XML as a separate content  
type/format, suitable for virtually nobody bat perhaps RFC Editor humans  
(this is a short-term solution requiring more work than #3 so I do not  
favor it).

> (accepted_by_xml2rfc - valid) smaller or even empty.

Yes, same for options #3 and #4.

> I don't believe that the Tools team has the mandate to choose the

Agreed.

Thanks,

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Mon, 29 Nov 2004 13:47:50 -0800

Sorry to open up a previously contentious topic, but:

Is it enough for the file to be valid XML, or does it have to pass
the DTD?  33% of the recent files at http://xml.resource.org/public/rfc/xml/
don't validate against the DTD.  ("Recent" means "since RFC 2451", which
was when the automatic conversion stopped generating invalid XML.  If I
include all the files, including the buggy automatically converted ones,
I end up with more like 70% don't validate).

3 of the files don't appear to be valid XML from xmllint's point of
view (one has -- inside a comment, two have [CDATA[]] sequences that
it chokes on but I don't see what's wrong with them so might be false
positives).

  Bill

---

From: "Alex Rousskov" <[email-masked]>
Date: Tue, 30 Nov 2004 09:12:33 -0700

On Mon, 2004/11/29 (MST), <[email-masked]> wrote:

> the DTD?

It has to pas the DTD, IMO.

My primary concern are [future] tools that use XML libraries that will not  
deal with broken XML. I suspect that some libraries will not deal with XML  
that does not pass DTD validation. Also, there is little pragmatic  
difference between enforcing basic XML validity and DTD-based validity. So  
we should get all the benefits for about the same price...

You should probably test against the latest DTD in [1], not the one in RFC  
2629.
[1] http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html

Alex.

---

From: Bill Fenner <[email-masked]>
Date: Tue, 30 Nov 2004 09:00:37 -0800

>[1] http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html

Of course, that's what I used.  (At least, the one that comes with
xml2rfc 1.26).

Alex.