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

Henrik Levkowetz henrik at levkowetz.com
Tue Feb 26 12:12:18 PST 2019


Hi Kent,

On 2019-02-26 20:47, Kent Watsen wrote:
> Hi Henrik,
> 
> Just responding to your comment about the "name" attribute (all your
> other comments were on the level).
> 
> While RFC 7991's description of the "name" attribute is compellingly
> close to the intended need, it doesn't explicitly state that "name"
> MAY or MUST NOT include relative directory paths. My naive
> reading/understanding is that the "name" is just the name of the file
> itself, the so called "basename" of a complete filepath value. At
> least, having "name" be defined to have this concrete purpose seems
> to have cross-cutting value.
> 
> My purpose seems twisted by comparison, to the extent that I question
> if any other tool would want or need to know an inclusion's original
> filepath value. On the other hand, "originalSrc" is semantically
> perfect for my needs. Let me turn this around and ask, why does
> preptool use "originalSrc" as opposed to "name" and, that being the
> case, how is it any different for xiax?

I don't have information beyond what's given in RFC 7991 and RFC 7998,
but in my mind the distinction is this:  The "src" and "originalSrc"
attributes are for the use of the preptool when moving external sources
into the xml file for the purpose of having one single archival entity
(file).  There is no semantic defined for reversing this.

Unfortunately, item 1 and 4 in Section 5.5.1 of RFC 7998[1] seems to set
up a situation where the "src" value will be moved to "originalSrc" in
some cases and not in others, and where pre-existence of "orgiginalSrc"
will change the behaviour.  This makes it unintended effects possible if
other tools also use the "originalSrc" value.  (Mmm.  I think we need to
revisit this part of RFC 7998 to make the conditions under which "src",
"originalSrc", or both will exist).

On top of this, Section 5.6.5 of RFC 7998 [2] specifies that "originalSrc"
be removed as part of publication; and Section 5.5.1 specifies that "src"
will be removed (in some?? cases) when "originalSrc" is filled in, which
leaves you with neither "src" or "originalSrc" in the published document...

I'd be happiest if other tools did not touch "originalSrc", and only
used "src" in order to point at external documents for inclusion by
xml2rfc.  That would avoid tool interdependencies.

We then need to either make "name" useful for your purpose, or provide
another way (possibly an xiax:name attribute) that will do.


Best regards,

	Henrik


[1]  https://tools.ietf.org/html/rfc7998#section-5.5.1
[2]  https://tools.ietf.org/html/rfc7998#section-5.6.5


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20190226/11a0c5db/attachment.asc>


More information about the rfc-interest mailing list