Subject: [rfc-i] Document validation references in the XML

From: Jay Daley <[email-masked]>
Date: Thu, 13 May 2021 10:02:59 +1200

There are some things around the way that I-Ds and RFCs are written with regards to XML validation that I don’t understand, and I was hoping someone could explain:

1.  Why don’t RFCs include a <!DOCTYPE> declaration when I-Ds do?  

2.  Why is the DTD pointed to by the <!DOCTYPE> declaration not a full DTD and just a set of entity declarations? 

3.  Why is the <?xml-model/> processing instruction [1] not used to point to the RNC schema?

cheers
Jay

[1]  https://www.w3.org/TR/xml-model/

-- 
Jay Daley
IETF Executive Director
[email-masked]

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 May 2021 01:09:33 +0200

Hi Jay,

these are pretty much generic XML questions, so I’ll try to answer them even if I have very little idea what specific tools are doing here in RFCXML land.

> 1.  Why don’t RFCs include a <!DOCTYPE> declaration when I-Ds do?  

The DTD in the <!DOCTYPE> is SGML legacy that XML still needed until better document type definition (“schema”) languages came along.
They are not needed (and actually shunned) on “real” XML documents.
SGML documents essentially are unparsable without a DTD as declared in the DOCTYPE, but XML can be parsed without a DTD (if the document type has been designed not to require the insertion of default values).

Inherited from SGML, the DOCTYPE subset (I’m forgetting the exact proper names here) also is the place that entity declarations are made.
These are needed for external entities (which we use for bibxml unless we use the horrible ad-hoc PIs or XInclude), but also for internal entities (except for the five pre-defined entities &lt; &gt; &amp; &quot; &apos; [2]).

(Internal) character entities such as &nbsp; were popular in SGML and thus in HTML; they need to be declared in the DOCTYPE subset.
This is what rfc2629.dtd does via its foo.ent components.
These are no longer needed in a Unicode-enabled environment, but as long as RFCXML kept up the pretense of ASCII, the alternative for entering the needed beyond-ASCII characters would have been character references (&#160; instead of &nbsp; etc.), and these are generally considered unfriendly to keyboard (which is why we now keyboard the actual characters).

All that legacy garbage can be removed when RFCs are published: external entities are included, character entities are replaced by native characters (or by character references).  But it is still perceived to be needed on the I-D side to continue supporting ingrained bad habits.

(I probably should delete the DOCTYPE declaration from kramdown-rfc’s output; this is in there so people can tweak the XML by hand, which hasn’t been necessary for a decade, while still making use of those existing habits.)

> 2.  Why is the DTD pointed to by the <!DOCTYPE> declaration not a full DTD and just a set of entity declarations? 

Because there is no need for the document type definition part of a DTD; this is handled by v2.rnc/v3.rnc (Relax-NG compact).
So only the character entity definitions remain.  Each time some someone enters an &nbsp; or some such, we are reminded of the need.

> 3.  Why is the <?xml-model/> processing instruction [1] not used to point to the RNC schema?

This is a bit “non-standard” (a W3C WG note only).
Actually, I didn’t know about this before you mentioned it, and I haven’t seen it in the wild.
(But then I left active work on XML about a decade before this WG note was published.)

Grüße, Carsten

> [1]  https://www.w3.org/TR/xml-model/

[2]: https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML

---

From: Jay Daley <[email-masked]>
Date: Thu, 13 May 2021 13:42:09 +1200

Thanks Carsten, some notes below: 

> On 13/05/2021, at 11:09 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Jay,
> 

I didn’t mean to give the impression it’s the technical details I’m interested, as it’s the strategy behind the decisions I’m after.

> SGML documents essentially are unparsable without a DTD as declared in the DOCTYPE, but XML can be parsed without a DTD (if the document type has been designed not to require the insertion of defau…

While not directly relevant, I do not agree with your characterisation of DTDs.  They are still actively used and taught with schema languages generally regarded as more advanced methods that are used when DTDs become too complex or too laborious to maintain.

> (I probably should delete the DOCTYPE declaration from kramdown-rfc’s output; this is in there so people can tweak the XML by hand, which hasn’t been necessary for a decade, while still making use…

If the only reason is so that people can insert character entities then why isn’t the rest of it simply <!ENTITY rfc (ANY)*> for trivial validation?  It looks as if the rest is intended for an attempt at meaningful validation. 

> So only the character entity definitions remain.  Each time some someone enters an &nbsp; or some such, we are reminded of the need.

That answers the question but I should correct my question (doesn’t change the answer) to say that I meant rfc2629-xhtml.ent as used in some DOCTYPE declarations ( <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> ) even though rfc2629-xhtml.ent does not declare itself to be a DOCTYPE (I didn’t realise that was possible but it works).

> (But then I left active work on XML about a decade before this WG note was published.)

This is surprisingly well used for a note.  In particular, XML editors honour it for validation.

A follow up question - Why are the documents left with no mention of how they are to be validated?  It appears to be another IETF thing where only those in the know actually understand that the documents are validated by a non-specified RNC.  There are at least two alternatives

1.  It is not uncommon for people to convert RNG/RNC into DTDs, accepting the loss of some features, just to ensure that documents are not left without a link to validation.
2.  Use <?xml-model> above and reference the RNC directly.  This is well supported and well understood.

(As an aside, the various versions of the RNC [3] are all backwards compatible)

Jay

[3]  https://github.com/rfc-format/v3grammar

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 May 2021 11:52:50 +1000

So I sparked off some debate about the use of symbolic entity references in draft XML.  It turns out that referencing a non-existent file for those breaks things in different ways.  I learned that the reason those exist is to support those who *do* edit the XML (the RPC).  Remembering that &#160; or &#xa0; is a non-breaking space is challenging but &nbsp; is easier to manage.  In that case it also avoids having a character that is otherwise indistinguishable from &#32;.  I can recognize the value of that, particularly when it comes to the final typesetting of a document.

Other than that, the less we draw on the legacy of XML, the better.  I would prefer that we not use namespaces at all.  And that we don't link to schema.  And that we never use processing instructions.  And we should never have to use DOCTYPE.  These are all XML misfeatures (with the possible exception of namespaces, which I'm willing to concede has uses in some contexts).

To that end -- even for the above -- I would be happier if the use of entity references were kept within the RPC.  Ideally, the same goes for XInclude, which is a great feature for managing common resources and one that I know is used widely.

When your XML needs to be interoperable, it should avoid those features.

On Thu, May 13, 2021, at 09:09, Carsten Bormann wrote:
> Hi Jay,
> 
> these are pretty much generic XML questions, so I’ll try to answer them 
> even if I have very little idea what specific tools are doing here in 
> RFCXML land.
> 
> The DTD in the <!DOCTYPE> is SGML legacy that XML still needed until 
> better document type definition (“schema”) languages came along.
> SGML documents essentially are unparsable without a DTD as declared in 
> the DOCTYPE, but XML can be parsed without a DTD (if the document type 
> has been designed not to require the insertion of default values).
> 
> Inherited from SGML, the DOCTYPE subset (I’m forgetting the exact 
> proper names here) also is the place that entity declarations are made.
> These are needed for external entities (which we use for bibxml unless 
> we use the horrible ad-hoc PIs or XInclude), but also for internal 
> entities (except for the five pre-defined entities &lt; &gt; &amp; 
> &quot; &apos; [2]).
> 
> (Internal) character entities such as &nbsp; were popular in SGML and 
> thus in HTML; they need to be declared in the DOCTYPE subset.
> These are no longer needed in a Unicode-enabled environment, but as 
> long as RFCXML kept up the pretense of ASCII, the alternative for 
> entering the needed beyond-ASCII characters would have been character 
> references (&#160; instead of &nbsp; etc.), and these are generally 
> considered unfriendly to keyboard (which is why we now keyboard the 
> actual characters).
> 
> All that legacy garbage can be removed when RFCs are published: 
> external entities are included, character entities are replaced by 
> native characters (or by character references).  But it is still 
> perceived to be needed on the I-D side to continue supporting ingrained 
> bad habits.
> 
> (I probably should delete the DOCTYPE declaration from kramdown-rfc’s 
> output; this is in there so people can tweak the XML by hand, which 
> hasn’t been necessary for a decade, while still making use of those 
> existing habits.)
> 
> Because there is no need for the document type definition part of a 
> DTD; this is handled by v2.rnc/v3.rnc (Relax-NG compact).
> So only the character entity definitions remain.  Each time some 
> someone enters an &nbsp; or some such, we are reminded of the need.
> 
> [2]: 
> https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references#Predefined_entities_in_XML

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 May 2021 12:06:48 +1000

> On 13 May 2021, at 11:52 am, Martin Thomson <[email-masked]> wrote:
> 

+1 to that. XML has many sharp edges, and can be abused in many ways. A conservative approach to its features is wise. 

It might be useful to consult more widely and codify best practice for our use of XML (without trying to boil any larger ocean).

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Jay Daley <[email-masked]>
Date: Thu, 13 May 2021 14:40:18 +1200

> On 13/05/2021, at 1:52 PM, Martin Thomson <[email-masked]> wrote:
> 

I would find it useful to understand why you want this - what does it achieve for the IETF?   What you are proposing has significant detrimental side effects around loss of functionality and loss of tools support that, as far as I can see, don’t just disappear but end up with us reinventing the wheel, sufficiently differently from the standard that we can’t use external tools, or simply doing things twice.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 13 May 2021 11:55:22 +0900

Hello Mark, others,

> It might be useful to consult more widely and codify best practice for our use of XML (without trying to boil any larger ocean).

First, there's RFC 3470. But I guess that doesn't apply here, because 
it's about protocols.

Second, the use of XML in RFCs and Internet Drafts should be covered by 
documents that don't just talk about whether to allow features such as 
schemas. We know we have a backlog in this area.

With respect to schemas, I guess I agree they shouldn't be linked in the 
document itself, or at least not in a way that makes the document depend 
on the schema. But we should definitely use them to keep the structure 
of our documents clean and organized. We just have to find out a good 
way to evolve the schema(s) when necessary, of course in a 
backwards-compatible way.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 May 2021 06:13:35 +0200

> While not directly relevant, I do not agree with your characterisation of DTDs.  They are still actively used and taught with schema languages generally regarded as more advanced methods that are u…

Well, yeah.

(COBOL is being actively used and taught, too.)

> If the only reason is so that people can insert character entities then why isn’t the rest of it simply <!ENTITY rfc (ANY)*> for trivial validation?  It looks as if the rest is intended for an atte…

This is not about validation, but about *defining* the character entities.  XML has no idea what an &nbsp; might be until you tell them.

> This is surprisingly well used for a note.  In particular, XML editors honour it for validation.

Learning every day.

> 2.  Use <?xml-model> above and reference the RNC directly.  This is well supported and well understood.

You seem to think adding stuff is good.  I tend to think less is more.

For an example how a mechanism randomly invoked can get in the way:

https://github.com/cabo/kramdown-rfc2629/issues/107

Yes, the cost of not providing validation instruction in files is one C-c C-s C-f (nxml-mode) per new RFCXMLv3 document I need to edit (nxml-mode finds the <rfc…> tag and infers RFCXMLv2).
Fortunately, these days that only happens during AUTH48...

Grüße, Carsten

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 13 May 2021 14:15:11 +1000

On Thu, May 13, 2021, at 12:40, Jay Daley wrote:
> > Other than that, the less we draw on the legacy of XML, the better.  
> 
> I would find it useful to understand why you want this - what does it 
> achieve for the IETF?   What you are proposing has significant 
> detrimental side effects around loss of functionality and loss of tools 
> support that, as far as I can see, don’t just disappear but end up with 
> us reinventing the wheel, sufficiently differently from the standard 
> that we can’t use external tools, or simply doing things twice.

I would like for the artifacts we produce to be as widely accessible as possible, and that means as narrow a profile as we can manage.

I don't think that this implies reinvention -- except to the extent that the XML format is a yet another authoring format -- or any sort of unworkable constraint.  It only requires acknowledging that the effects of functionality might need to be constrained such that it doesn't affect others.  I'd be interested in what feature you think we'd miss by adopting this sort of posture.

To take the example I gave before, if XInclude is a useful feature (and it very much is at most stages of the production cycle), then we should allow it in those places where its impact is understood to be acceptable.  Many tools won't need to support this feature and can treat those tags as inert, which works out fine.  On balance, XInclude is probably worth it within a certain scope.  That is, up until the point we publish, where we currently replace those tags, which is as it should be.  We do that to not only ensure that the content is stable, but to narrow the feature set for the (hopefully) large number of people who have to deal with the XML.  From my perspective, I use something like XInclude, but I don't submit drafts that have <xi:include> tags in them.  I know that others rely on it and the decision to accept that is probably worthwhile.

If the use of XML features had to be justified on those terms, that would be a good thing.

---

From: Jay Daley <[email-masked]>
Date: Thu, 13 May 2021 18:11:22 +1200

> On 13/05/2021, at 4:13 PM, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 

Sorry I wrote that wrong, it should have been <!ELEMENT rfc(ANY)*>. My point being that rfc2629.dtd has a lot of ELEMENT and ATTLIST content but I’m not sure why if it’s not intended for meaningful validation. 

> https://github.com/cabo/kramdown-rfc2629/issues/107

That’s not a random mechanism - that’s how it is meant to work. If you don’t want to have a URI call for a DTD each time that file is validated then you need to use XML Catalog [4] which just about every XML validator honours. I realise that to some this is evidence that XML is too complex and should be avoided but to me it’s evidence that we don’t XML very well. 

[4] https://en.wikipedia.org/wiki/XML_catalog

Jay

—  
Jay Daley
IETF Executive Director

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 May 2021 08:26:41 +0200

On 13. May 2021, at 08:11, Jay Daley <[email-masked]> wrote:
>> https://github.com/cabo/kramdown-rfc2629/issues/107 <https://github.com/cabo/kramdown-rfc2629/issues/107>
> That’s not a random mechanism - that’s how it is meant to work. If you don’t want to have a URI call for a DTD each time that file is validated

Jay, 

I don’t care about validation!
I want my documents processed.  
In an as stand-alone, predictable, brisk fashion as possible.
Random network accesses out of the bowels of documents open up points of failure that I don’t need (and Lars apparently didn’t need either).

(The specific problem in the example here is caused by the external tool mscgen.  I just brought this up as an example for why you don’t want mechanisms triggered that have unpredictable outcomes.  When I have time,I’ll probably put in some preprocessing of the mscgen output that removes the DTD reference.)

> then you need to use XML Catalog [4] which just about every XML validator honours. I realise that to some this is evidence that XML is too complex and should be avoided but to me it’s evidence that we don’t XML very well. 

Again, I don’t want to do XML very well, I want to get work done.
We have ~/.cache/xml2rfc.
I think the trend in I-D-template and its docker configs is to pre-load caches to the brim, in order to minimize exposure to random dereferencing failures.
That is a valid mitigation, but not having the problem of random dereferencing in the first place would be better.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 May 2021 10:04:17 +0200

Am 13.05.2021 um 03:42 schrieb Jay Daley:
> ...
> If the only reason is so that people can insert character entities then
> why isn’t the rest of it simply <!ENTITY rfc (ANY)*> for trivial
> validation?  It looks as if the rest is intended for an attempt at
> meaningful validation.
> ...

I don't quite understand. What would that achieve with respect to
validation?

> ... >>> 3.  Why is the <?xml-model/> processing instruction [1] not used to
>>> point to the RNC schema?
>>
> A follow up question - Why are the documents left with no mention of how
> they are to be validated?  It appears to be another IETF thing where
> only those in the know actually understand that the documents are
> validated by a non-specified RNC.  There are at least two alternatives

That's not an IETF thing.

Pointing to a schema for the purpose of local validation or editing is
fine. If your editor supports a PI to point to a schema file, that's
great. It can be used, and that's exactly what PIs are for.

Now when processing the file with xml2rfc (or any other processor...),
the story is different. These processors are not schema-driven, and they
expect a certain vocabulary. It really doesn't matter what the sender
thinks this conforms to. The processor will use the vocabulary it was
built for (or one of these), and will use *that* schema file for validation.

> ...

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 May 2021 08:27:22 -0400

Carsten Bormann <[email-masked]> wrote:
    > I think the trend in I-D-template and its
    > docker configs is to pre-load caches to the brim, in order to minimize
    > exposure to random dereferencing failures.

Gosh, I wish we'd gotten URN resolvers deployed ubiquitously.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Jay Daley <[email-masked]>
Date: Fri, 14 May 2021 10:39:21 +1200

> On 13/05/2021, at 8:04 PM, Julian Reschke <[email-masked]> wrote:
> 

> In an as stand-alone, predictable, brisk fashion as possible. 

As we all know, rfc2629.dtd is not the canonical schema, the unnamed RNC is.  However rfc2629.dtd does not just contain entity references, it also contains a schema but that schema is from 2008 and by comparison to the current RNC is neither minimal nor incomplete, it’s somewhere in between.  It may even have some critical differences, I haven’t checked.

Currently, anyone who loads an I-D that includes the DOCTYPE statement pointing to the rfc2629.dtd into an XML editor/Emacs with nxml-mode/etc will be validating against rfc2629.dtd unless they specifically turn it off, because that’s how those tools work.  

My question is - what is the point of having a DTD that is non-canonical and that contains a schema quite different from the canonical schema and yet is regularly used in our I-Ds and therefore triggers validation of those I-Ds - what purpose does this serve? 

My answer is that it doesn’t serve any purpose but actively wastes time/resource and misdirects people, therefore we should do one of the following instead:

1.   Recommend the use of rfc2629-html.ent in the DTD instead of rfc2629.dtd and that still provides all the character entities without the schema.  That results in no validation.

2.   Create an rfc2629-v3.dtd that keeps the character entities but replaces the schema with the absolute minimum of <!ELEMENT rfc(ANY)*> and recommend that is used.  That results in trivial validation

3.   Create an rfc2629-v3.dtd that is generated by trang from the v3 RNC and recommend that is used.  That results in meaningful but incomplete validation (assuming the RNC does not fully convert to a DTD).

4.   Do 1 above and also recommend the use of <?xml-model …> pointing to the RNC (local copy).  That results in meaningful and complete validation.

> built for (or one of these), and will use *that* schema file for validation.

That’s not correct.  xml2rfc does multiple levels of validation and one of the first is schema validation against the RNC (until recently the only place the RNC could be obtained from was the xml2rfc code). 

I go back to my point from my earlier message - we have designed a system that uses a defined schema and validates against that schema but then hidden away the schema.  By doing that we significantly reduce the benefits that people could get from using modern xml tools (including emacs nXML-mode), such as the hugely beneficial "schema-sensitive editing".

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 14 May 2021 08:54:50 +1000

> My question is - what is the point of having a DTD that is 
> non-canonical and that contains a schema quite different from the 
> canonical schema and yet is regularly used in our I-Ds and therefore 
> triggers validation of those I-Ds - what purpose does this serve? 
 >
> My answer is that it doesn’t serve any purpose but actively wastes 
> time/resource and misdirects people, 

I agree.  A bad DTD is bad.

> therefore we should do one of the following instead:

I have no problem with the inclusion of PIs or other useful and accurate additions that don't affect usage.  But I do think that we need to avoid some of your options.  Not because they are wrong, but because of the side-effects.  Unconfigured parsers (those without XML catalogues) will make network requests for DTDs or schema (or XSLT...) that make processing more fragile.

Exposure to secondary resources is not a feature, it's a liability.  It means that you can't work on a plane (hah), and you can't work when tools.ietf.org is down yet again.

xml2rfc adds rfc2629-html.ent as a DTD, but provides that as just a string literal.  The effect in most processors is that it attempts to load a local file.  Oddly enough, this causes problems because that file is almost never in that location.  The same goes for any schema or XSLT file.  (I have the same complaint about metadata.min.js and rfc-local.css for the same reasons; both have bad defaults.)

My (strong) preference is that the XML files are - in as many cases as reasonable - usable without special setup or environment.  No XML catalogues.  I can make an exception for XInclude in some cases, but I would not have that be a default configuration of any tool.

---

From: Jay Daley <[email-masked]>
Date: Fri, 14 May 2021 11:03:35 +1200

> On 14/05/2021, at 10:54 AM, Martin Thomson <[email-masked]> wrote:
> 
> My (strong) preference is that the XML files are - in as many cases as reasonable - usable without special setup or environment.

That’s a requirement that can be fulfilled by ensuring any schema PI does not have a full path, only the file name, and that schema file is available locally.  These schema files after all are long term stable.

Jay

>  No XML catalogues.  I can make an exception for XInclude in some cases, but I would not have that be a default configuration of any tool.

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 May 2021 01:57:23 +0200

> Currently, anyone who loads an I-D that includes the DOCTYPE statement pointing to the rfc2629.dtd into an XML editor/Emacs with nxml-mode/etc will be validating against rfc2629.dtd unless they spe…

Maybe we should reveal to the validating public that nxml users should have these lines in the schemas.xml:

  <documentElement prefix="" localName="rfc" typeId="RFC”/>
  <typeId id="RFC" uri="v3.rnc”/>

For nostalgia, add a 

  <typeId id=“v2" uri="v2.rnc”/>

So you can C-c C-s C-t into it.

The use of character entities should really be discouraged, not facilitated, but...

A natural name for an entity-bearing include file into the document subset (or whatever that is called) would be rfcNNNNN.dtd, where NNNNN is the number of the RFC that defines v3.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Fri, 14 May 2021 05:48:49 +0200

> As we all know, rfc2629.dtd is not the canonical schema, the unnamed RNC is.  However rfc2629.dtd does not just contain entity references, it also contains a schema but that schema is from 2008 and…

Yes. But.

"rfc2629.dtd" is nothing more than a filename. Based on that, you really
don't know what's in it. (FWIW, the "latest" change seems to be from 2011).

> Currently, anyone who loads an I-D that includes the DOCTYPE statement pointing to the rfc2629.dtd into an XML editor/Emacs with nxml-mode/etc will be validating against rfc2629.dtd unless they spe…

Unless I'm missing something, what's in the ID's XML depends on what the
author submitted. And, FWIW, it it's a V2 document, the vocabulary would
be indeed correct for some value of "correct".

Are you suggeting that we should reject (or "fix") these at submission time?

> My question is - what is the point of having a DTD that is non-canonical and that contains a schema quite different from the canonical schema and yet is regularly used in our I-Ds and therefore tri…

That would need to be answered by those who submit that XML (or write
the tools that produce it).

> 1.   Recommend the use of rfc2629-html.ent in the DTD instead of rfc2629.dtd and that still provides all the character entities without the schema.  That results in no validation.

The problem with that is that the submitted XML is not standalone, and
depends on what the recipient thinks should be in that file (and yes,
this applies to all cases where a secondary file is referenced here).

> 2.   Create an rfc2629-v3.dtd that keeps the character entities but replaces the schema with the absolute minimum of <!ELEMENT rfc(ANY)*> and recommend that is used.  That results in trivial valida…

That would make *anything* valid; so I don't see how this helps.

> 3.   Create an rfc2629-v3.dtd that is generated by trang from the v3 RNC and recommend that is used.  That results in meaningful but incomplete validation (assuming the RNC does not fully convert t…

That already exists (in xml2rfc's SVN: ./cli/xml2rfc/data/v3compat.dtd).

> 4.   Do 1 above and also recommend the use of <?xml-model …> pointing to the RNC (local copy).  That results in meaningful and complete validation.

We need to distinguish between what's *needed* (defining entities that
are used), and what's truly optional (a reference to a schema).

If this is about fixing XML that is not stand-alone with respect to what
entities are declared: yes, if there are tools producing these, these
should be fixed.

Wrt declaring a DTD/schema in use: that should really be the decision of
the author. It's meaningless for the processing by xml2rfc.

> That’s not correct.  xml2rfc does multiple levels of validation and one of the first is schema validation against the RNC (until recently the only place the RNC could be obtained from was the xml2r…

That is misleading.

xml2rfc indeed validates documents based on xml2rfc's version of the
RNG. But that's just the validation. You can't swap the RNG with
something else and expect xml2rfc to process the file.

> I go back to my point from my earlier message - we have designed a system that uses a defined schema and validates against that schema but then hidden away the schema.  By doing that we significant…

This whole discussion seems to be based on the "xml-model" PI that you
mentioned. I confess I was not aware of it. Nor do I use any tools that
process it.

If it works for a given XML editor, that's fine. There's no reason for
an author not to use it. But it's just a hint, and will have no effect
whatsoever on how xml2rfc will actually process that file.

Best regards, Julian

---

From: Jay Daley <[email-masked]>
Date: Tue, 18 May 2021 14:18:49 +1200

> On 14/05/2021, at 3:48 PM, Julian Reschke <[email-masked]> wrote:
> 
> 
> 

My interest is making it easier for those who choose to write I-Ds in XML to do so as easily and productively as possible.  Most of that can be achieved through better documentation.

> mentioned.

Yes this whole discussion is based on that - that is the closest thing to an official way to associate an RNG/RNC schema and it is the benefit of that automatic association and replacing the incorrect automatic association with a DTD that I think is missing.    

> I confess I was not aware of it. Nor do I use any tools that
> process it.

That surprises me as it’s been around for a long time.  For example, support was added to libxml2 in 2012.  

> whatsoever on how xml2rfc will actually process that file.

Indeed, nor should it.  xml2rfc is a single schema validator, not a general purpose tool.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]