[rfc-i] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt

Kent Watsen kent+ietf at watsen.net
Tue Feb 26 08:24:54 PST 2019

Hi Julian,

> I notice that you seem to propose new extension attributes for stuff you can already do without. See, in particular,
> https://greenbytes.de/tech/webdav/rfc7991.html#element.artwork.attribute.name
> https://greenbytes.de/tech/webdav/rfc7991.html#element.sourcecode.attribute.name

Yes, I was originally using the "name" attribute, but then I found that prep tool was using "originalSrc",
which made more since to me, since the goal is to capture the entire path (more than just the name).

> https://greenbytes.de/tech/webdav/rfc7991.html#includingexternal <https://greenbytes.de/tech/webdav/rfc7991.html#includingexternal>

I'm familiar with XInclude, but note that more than just including a file is going on (e.g., date substitutions,
content generation, validation, etc.).

> The following discussion about CODE BEGIN etc should also be interesting:
> <https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/8>

I hadn't seen this issue before, but I did see Henrik's comments about markers in 
draft-levkowetz-xml2rfc-v3-implementation-notes.  FWIW, the "xiax:markers" attribute
is primarily only to support xml2rfc v2 documents; v3 documents can just use the built-in
"markers" attribute.

That said, I think that markers are, in general, a mistake.  That they were only put their
for tools scrapping plain-text documents.   Assuming tools extract from XML, then no
markers are needed, neither for framing (to aid the scraping process) or for capturing
the file's name (which is better served by the aforementioned "name" attribute.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20190226/f4c15c15/attachment.html>

More information about the rfc-interest mailing list