[rfc-i] draft-hoffman-rfcexamples-04, "3. Example of a v3 Document"
HANSEN, TONY L
tony at att.com
Mon Feb 29 07:37:18 PST 2016
On 2/29/16, 1:19 AM, "Julian Reschke" <julian.reschke at gmx.de> wrote:
>On 2016-02-29 04:55, HANSEN, TONY L wrote:
>> I've looked at convertv2v3. The reference exists in the original v2 doc and is just preserved. That is, this is the entry in the v2 doc:
>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>> <!ENTITY RFC2119 SYSTEM
>> All of the ENTITY references are pulled out and changed to x:includes. Then the remaining DOCTYPE was then just left alone, with no special checks as to what DTD was being referenced.
>> I guess I can add some code to check for this special case and remove the DTD entirely if it's an rfc2629.dtd reference.
>Well, there are other cases that need to be considered. What would you map
><!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
> <!-- re-declare " " as code point 160 (non-breaking space) -->
> <!-- you may need this for UAs that do not read external DTDs -->
> <!ENTITY nbsp
> " ">
Right now, that DOCTYPE declaration would be passed through.
After I add code to remove the reference to rfc2629.dtd, you would get:
<!DOCTYPE rfc [
<!-- re-declare " " as code point 160 (non-breaking space) -->
<!-- you may need this for UAs that do not read external DTDs -->
In other words, what is there would be preserved.
>In general, how does the conversion treat Internal Entities defined in
>the document to-be-converted? And how does it treat those defined by
>rfc2629.dtd (and included files)?
This is what my prototype conversion code does currently. Help would be appreciated.
If you include a reference to an undefined entity, the code currently tries adding references to rfc2629-xhtml.ent rfc2629-other.ent, and &rfc.number; to whatever DOCTYPE is there, then reparses the file. If no DOCTYPE is present, it declares one with rfc2629.dtd.
Based on this discussion, the reference to rfc2629.dtd should probably be changed to individual ENTITY declarations. I can insert a DOCTYPE without referencing rfc2629.dtd.
One issue that should be noted is that &rfc.number; is internally pre-defined by the current XML2RFC processors that the RFC Production Center uses, and I don't think that functionality should be lost.
More information about the rfc-interest