Subject: [rfc-i] sourcecode type="json"

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Oct 2021 21:26:33 +0200

https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html

includes a number of JSON examples, or at least it claims so.

We created 15 examples that are marked »<sourcecode type=“json”>«.  Of these, 3 are JSON, and 12 are a single member (or two) without surrounding braces, meant to be put into larger JSON objects.

E.g.:
https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-08.html#section-3.2-6

These braces can of course be added, but they are really noise distracting from the content that is in these members (and the objects formed this way may be valid JSON, but they usually aren’t valid SDF).

Should we introduce a new sourcecode type “json-members”?
Or should we bite the bullet and add the noise to get real JSON texts?

Grüße, Carsten

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Oct 2021 17:18:39 -0400

> Or should we bite the bullet and add the noise to get real JSON texts?

This isn't a new problem. The same issue arises with all sorts of 
syntax. In the case of sip this led to having both message/sip and 
message/sipfrag mime types.

IMO it would be best to have a general purpose modifier that modifies a 
type to indicate a fragment of the same type.

	Thanks,
	Paul

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2021 09:58:09 +1100

For http, we use 'http-message', which is defined to be either a full *or* partial message. Remember, this is not a media type...

> On 27 Oct 2021, at 6:26 am, Carsten Bormann <[email-masked]> wrote:
> 
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

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

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2021 20:36:05 -0400

>For http, we use 'http-message', which is defined to be either a full *or* partial message. Remember, this is not a media type...

Right.  We have lots of sourcecode which is a chunk of a program, not a full program.

If it's a chunk of JSON, call it JSON.

R's,
John

>> We created 15 examples that are marked »<sourcecode type=“json”>«.  Of these, 3 are JSON, and 12 are a single member (or two)
>without surrounding braces, meant to be put into larger JSON objects.
>> 
>> E.g.:
>> These braces can of course be added, but they are really noise distracting from the content that is in these members (and the objects
>formed this way may be valid JSON, but they usually aren’t valid SDF).
>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2021 08:21:00 +0200

Thank you all for your great feedback.

> On 27. Oct 2021, at 02:36, John Levine <[email-masked]> wrote:
> 

That is certainly true of e.g. C language — there is no expectation that C language in a sourcecode block is a complete program.

The question is really why are we marking up sourcecode as to its type in the first place.

One need would be for rendering.
But amazingly, it’s 2021 and we don’t yet have syntax coloring in RFCs.
This, however, could be added from the information that is in the XML today; full JSON texts and JSON fragments probably can be handled by the same coloring engine.
(The coloring would be heuristic during rendering, not embedded in the XML; only the type information would be needed to select the appropriate heuristics.)

With FDT languages such as ABNF or CDDL, extraction is needed; since some ABNF/CDDL is just for exposition, extraction needs the distinction between that and the normative ABNF/CDDL; in recent RFCs that has sometimes been done by using the @name attribute alongside @type.

Apart from that, the needs I’m more interested in are as a support for authoring.
This is mostly based on extraction, but also on the ability to run CI processes on the sourcecode extracted (per-block and between them).
Additional metadata may be required as input to e.g. a validation process; YANG puts that into the “<CODE BEGINS>” line.

The specific question came up because I was adding some CI to the SDF spec repo.
Inevitably, that made me find one typo, which although not obscuring the intention, if undetected would sooner or later have led to an errata report.
I expect authoring tools like kramdown-rfc will provide some of this validation as a matter of course, but that requires metadata.
Of course, these don’t *have* to be saved in the XML, but for practical reasons much of the CI processing operates on the XML output.

So I’d rather have a way to embed metadata that is required for automatic processing (extraction, validation) in the XML.
This would also help with maintaining validation through the RFC production.

My current CI code has to guess whether type=json means JSON text or JSON fragment (where the latter is well-defined for SDF, but maybe not in general).
My concern is less that this adds 5 lines of code to the now 19-line validation script.
I’d rather not require that a validation step needs to guess the author’s intention.

(The next step then is to add CDDL validation for the JSON texts and fragments.
Additional metadata needed here is: which specific CDDL rule is intended to govern that text/fragment.
I’m not too happy if I need to cram that into @name, but it looks that way.) 

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Oct 2021 09:05:09 +0200

> But amazingly, it’s 2021 and we don’t yet have syntax coloring in RFCs.

It depends on the HTML generator that you use :-). See, for instance,
<https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.2>.

> (The coloring would be heuristic during rendering, not embedded in the XML; only the type information would be needed to select the appropriate heuristics.)

Yes.

> Of course, these don’t *have* to be saved in the XML, but for practical reasons much of the CI processing operates on the XML output.

+1 on that.

> ...

Best regards, Julian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2021 11:09:50 -0400

> For http, we use 'http-message', which is defined to be either a full *or* partial message. Remember, this is not a media type...

While its not media type the problem is the same.

Part of the problem is that "sourcecode type" isn't well defined at all. 
The definition seems to be in RFC 7991 section 2.48.4. The legal values 
are defined there by enumeration, but also with the following qualification:

    The RFC Series Editor will maintain a complete list of the preferred
    values on the RFC Editor web site, and that list is expected to be
    updated over time.

Note that this isn't an iana registry, nor does it have any rules for 
how updates are to be judged. This bothers me.

	Thanks,
	Paul

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2021 17:14:29 +0200

On 2021-10-27, at 17:09, Paul Kyzivat <[email-masked]> wrote:
> 
> […]
> Part of the problem is that "sourcecode type" isn't well defined at all. The definition seems to be in RFC 7991 section 2.48.4. The legal values are defined there by enumeration, but also with the following qualification:
> 
> Note that this isn't an iana registry, nor does it have any rules for how updates are to be judged. This bothers me.

https://www.rfc-editor.org/materials/sourcecode-types.txt

The list is indeed owned by the RFC editor, and makes progress based on publishing RFCs that need these types.
Just as we got cbor-diag and cbor-pretty added to this list, we might want to add something for json.  Or maybe not, and that was part of the reason I was asking whether we have a common opinion on this subject.

Grüße, Carsten

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2021 11:17:51 -0400

> One need would be for rendering.

IMO one key reason for marking these up in RFCs and drafts is because we 
expect formal language used in RFCs to be verified as part of the 
approval process, and marking it up provides a starting point for 
automated verification.

This is also a reason for distinguishing syntactically complete 
sourcecode from fragments that are not syntactically complete.

	Thanks,
	Paul

---

From: Pete Cordell <[email-masked]>
Date: Tue, 26 Oct 2021 21:18:58 +0100

> Or should we bite the bullet and add the noise to get real JSON texts?

For a fragment of something bigger in free-form text I'd add ellipsis 
either side, e.g.:

    ...
    "namespace": {
      "cap": "https://example.com/capability/cap",
      "zcl": "https://zcl.example.com/sdf"
    },
    "defaultNamespace": "cap",
    ...

Is there not a precedent using things other than JSON (such as code 
samples) that offers guidance on whether to keep with a type="json" or 
add a new type?

HTH,

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2021 14:39:00 -0400

It appears that Carsten Bormann  <[email-masked]> said:
>One need would be for rendering. ...

>With FDT languages such as ABNF or CDDL, extraction is needed; ...

>Apart from that, the needs I’m more interested in are as a support for authoring.

That seems about right.  If we really care about extraction, we'd need attributes with
more clues about how to do it since in most languages unlike ABNF, the order in which
you paste fragments together makes a difference, and you often need hints about what
version of the language, e.g. python 2 vs python 3.

I don't think we should try and solve this problem now, just throw it on the heap of
things to donsider for xml2rfc v4.

R's
John

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2021 10:03:26 +1100

> On 28 Oct 2021, at 2:09 am, Paul Kyzivat <[email-masked]> wrote:
> 

In this case, we use one validator for both forms:
  https://github.com/mnot/rfc-http-validate

> Note that this isn't an iana registry, nor does it have any rules for how updates are to be judged. This bothers me.

I agree. Perhaps this is something the RSWG should take on when it's constituted.

Cheers,

---

From: tom petch <[email-masked]>
Date: Thu, 28 Oct 2021 09:31:33 +0100

On 27/10/2021 16:17, Paul Kyzivat wrote:
>> That is certainly true of e.g. C language — there is no expectation
>> that C language in a sourcecode block is a complete program.
>>

May be.

Marking YANG with 'CODE BEGINS' 'CODE ENDS' changes the copyright and 
makes the code usable which it otherwise would likely not be.  This 
applies to the syntactically complete and the syntactically incomplete 
but not to examples that are there solely for illustration.

Tom Petch

>> This, however, could be added from the information that is in the XML
>> today; full JSON texts and JSON fragments probably can be handled by
>> the same coloring engine.
>> (The coloring would be heuristic during rendering, not embedded in the
>> XML; only the type information would be needed to select the
>> appropriate heuristics.)
>>
>> With FDT languages such as ABNF or CDDL, extraction is needed; since
>> some ABNF/CDDL is just for exposition, extraction needs the
>> distinction between that and the normative ABNF/CDDL; in recent RFCs
>> that has sometimes been done by using the @name attribute alongside
>> @type.
>>
>> This is mostly based on extraction, but also on the ability to run CI
>> processes on the sourcecode extracted (per-block and between them).
>> Additional metadata may be required as input to e.g. a validation
>> process; YANG puts that into the “<CODE BEGINS>” line.
>>
>> Inevitably, that made me find one typo, which although not obscuring
>> the intention, if undetected would sooner or later have led to an
>> errata report.
>> I expect authoring tools like kramdown-rfc will provide some of this
>> validation as a matter of course, but that requires metadata.
>> Of course, these don’t *have* to be saved in the XML, but for
>> practical reasons much of the CI processing operates on the XML output.
>>
>> So I’d rather have a way to embed metadata that is required for
>> automatic processing (extraction, validation) in the XML.
>> My current CI code has to guess whether type=json means JSON text or
>> JSON fragment (where the latter is well-defined for SDF, but maybe not
>> in general).

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Oct 2021 11:48:11 +0200

> but not to examples that are there solely for illustration.

I keep hearing that, but it is not true.

YANG is (and has been for long) covered by
<https://trustee.ietf.org/documents/trust-legal-provisions/code-components-list-3/>,
and thus does not require the use of "CODE BEGINS"/"CODE ENDS".

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 14:03:12 +0200

> and thus does not require the use of "CODE BEGINS"/"CODE ENDS".

It is still required by YANG, but not for legal reasons:

The CODE BEGINS for a YANG module has parameters [1] that cannot be put into the “markers=” attribute [2].

Grüße, Carsten

[1]: Please dig out reference here...
[2]: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#section-2.53.2

---

From: tom petch <[email-masked]>
Date: Thu, 28 Oct 2021 16:43:08 +0100

> The CODE BEGINS for a YANG module has parameters [1] that cannot be put into the “markers=” attribute [2].

My recollection of the work that went into YANG Guidelines is different, 
that it was decided that the trust legal provisions were too vague and 
that this was nailing them down to be clear where it applied.

Tom Petch

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 18:04:19 +0200

On 2021-10-28, at 17:43, tom petch <[email-masked]> wrote:
> YANG Guidelines

Thank you.

https://datatracker.ietf.org/doc/html/rfc8407#section-3.2
https://datatracker.ietf.org/doc/html/rfc7950#section-5.2

The MUST at the start of Section 3.2 of RFC 8407 is fulfilled by markers=“true”; the SHOULD following it requires setting name=“[email-masked]” as well, both on the artwork element, leading to:

~~~ yang
module foo ...
~~~
{: title="foo" artwork-markers="true" artwork-name="foo@...yang"}

Note that RFC8407 also uses the presence or absence of <CODE BEGINS> to distinguish example modules from normative ones, so you only set markers=“true” for the latter.  The attribute name= is ignored by XML2RFC if markers=“true” is not set, so it can be used as a side channel between the authors and their tools.

Grüße, Carsten

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Oct 2021 10:06:56 -0600

> I agree. Perhaps this is something the RSWG should take on when it's constituted.

It's not clear to me how this falls under IANA's mission to "allocate 
and maintain unique codes and numbering systems that are used in the 
technical standards that drive the Internet", since these sourcecode 
types are an editorial matter for the RFC Series.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 18:18:16 +0200

On 2021-10-28, at 18:06, Peter Saint-Andre <[email-masked]> wrote:
> It's not clear to me how this falls under IANA's mission to "allocate and maintain unique codes and numbering systems that are used in the technical standards that drive the Internet", since these sourcecode types are an editorial matter for the RFC Series.

I don’t think Mark really suggested using IANA here.  Involving the RSWG in moving the list forward sounds like a good idea, not necessarily with a consensus call per change, but maybe with the power to speak up.

Grüße, Carsten

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Oct 2021 10:19:58 -0600

> I don’t think Mark really suggested using IANA here.  Involving the RSWG in moving the list forward sounds like a good idea, not necessarily with a consensus call per change, but maybe with the pow…

+1 to that. At the least, it might help to have a lightweight policy 
that the RPC follows when working with authors, which could include 
notifiying the relevant list(s).

Peter

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2021 12:22:25 -0400

>types are an editorial matter for the RFC Series.

An IANA registry would be silly, since this is just a convention for our internal
publishing process and has nothing to do with any implementation of any IETF standard.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Oct 2021 18:27:40 +0200

> that this was nailing them down to be clear where it applied.

If those are too vague than this really needs to dicussed; everybody
else (outside YANG) is reyling on them to be sufficient. Details would
be appreciated.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Oct 2021 10:30:38 -0600

> publishing process and has nothing to do with any implementation of any IETF standard.

Indeed, presenting this as a set of sourcecode types that could be used 
more widely might lead both to confusion about the purpose of the list 
and bloat as people ask for the addition of their preferred types.

Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Oct 2021 17:11:39 -0400

On 10/28/21 12:30 PM, Peter Saint-Andre wrote:
>>>>> Note that this isn't an iana registry, nor does it have any rules 
>>>>> for how updates are to be judged. This bothers me.
>>>>

I'm not concerned that this be under iana. My reference to that is 
because it comes with a well defined mechanism(s) to manage updates to 
such a list, and an need for clear definition of what entries in the 
list mean.

I don't see that now. Its a bunch of names of "languages" of interest 
without any semantics.

For instance, at least in some cases we want the sourcecode to be 
validated. (Its an item in the shepherd writeup.) But where is the link 
between the name in the list and the actual definition of the language? 
I would like the list to contain references.

This is further complicated by the discussion of language fragments. If 
you only have a fragment then you are limited in how much validation you 
can do and the tools you can use to do it.

What is driving me here is the need to validate ABNF. In my experience 
formal evaluation is rarely done, because for the ABNF usages I am 
familiar with in document the ABNF is rarely free standing. Doing a 
proper validation requires extracting blocks of ABNF from multiple 
documents, merging them, and sometimes doing other reformatting before 
it can be properly checked using BAP.

I've seen fragments of ABNF used in a variety of ways:

1) Examples, perhaps just a single rule, typically with references to 
other rules not defined in the fragment. The definitions might be 
defined in other fragments, only described in text, or not defined at all.

2) A complete chunk of ABNF that has been broken into multiple fragments 
interspersed among text discussion of it, perhaps spread across multiple 
sections of a document.

3) A semi-complete chunk of ABNF with some undefined rules. Text or 
comments in the ABNF refer to other documents for definition of the 
missing rules.

4) A combination of (1) and (3), where the fragments are copies of 
portions of the full ABNF, accompanied with discussion.

Required validation strategies vary for these cases. They typically 
require quite a bit of hands-on, which discourages doing it often (or 
ever). It is really easy to say "there was just a small change in this 
version - its obvious that it is ok".

I would like to see some kind of framework for automated verification of 
sourcecode. The xml is just a piece of that, but an important piece.

	Thanks,
	Paul

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 23:42:46 +0200

This is becoming a bit ABNF-specific, but I’ve run into that problem as well.

Ideally, I’d like to be able to write a generic script that looks at JSON, ABNF, YANG, … in a draft and tells me what’s wrong.

A lot of insights that such a tool will need to consider are in [1]  — I don’t want to repeat them all here.

[1]: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/195

In particular, we ran into the “exposition only” vs. “normative” part in RFC 8990, and came up with a solution [2] that works for this RFC, but not in general.

[2]: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/195#issuecomment-850815497

> 1) Examples, perhaps just a single rule, typically with references to other rules not defined in the fragment. The definitions might be defined in other fragments, only described in text, or not defined at all.

You are missing:

1a) ABNF rule right-hand—sides (production “elements” in RFC 5234); exposition or normative.

See RFC 8288 for a ton of these.

This was pre-8650 (i.e., RFCXMLv2), but the XML source I saved from that time has type=“abnf2616” both for RHS only and full rules (2616 because it uses the extended ABNF from RFC 2616, which is similar to that from RFC 822, with #rulename for a comma-separate list).

> 2) A complete chunk of ABNF that has been broken into multiple fragments interspersed among text discussion of it, perhaps spread across multiple sections of a document.

That was the problem we solved in RFC 8990.
(The tool support for that is easy in CDDL, as CDDL allows having the same rule twice, so you just concatenate the extracted fragments with the normative part and check the result.)

> 3) A semi-complete chunk of ABNF with some undefined rules. Text or comments in the ABNF refer to other documents for definition of the missing rules.

ABNF-specific problem.  We should mitigate this a bit for ABNF, stay tuned…

> 4) A combination of (1) and (3), where the fragments are copies of portions of the full ABNF, accompanied with discussion.

Or may this was the problem we solved in 8990…
But I think we now know that, beyond sourcecode types, we need to distinguish exposition sourcecode from full sourcecode (and example from normative in the latter).  Add in deliberately broken examples...

> Required validation strategies vary for these cases. They typically require quite a bit of hands-on, which discourages doing it often (or ever). It is really easy to say "there was just a small change in this version - its obvious that it is ok".

Yeah.  I did this once, in RFC 7049, at the cost of two errata :-)
Right, let me add:

(5) sourcecode snippets that are integrated inline into the paragraphs of text, but still need to be validated.

> I would like to see some kind of framework for automated verification of sourcecode. The xml is just a piece of that, but an important piece.

This is clearly a larger development project, but a highly desirable one.
Getting sourcecode types right is going to be a small, but important element for that.
(Note that his is mostly going to be a tool that authors need to be comfortable using, but that will need to be applied at the RPC as well.)

Grüße, Carsten

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Oct 2021 19:30:42 -0400

Carsten,

Of list...

> (Note that his is mostly going to be a tool that authors need to be comfortable using, but that will need to be applied at the RPC as well.)

I agree. And I'm interested in working on the larger project.

I looked for awhile at extensions to ABNF for "includes" that could 
reference (among other things) ABNF embedded in a different RFC/draft. 
But it looked to be impossible at the time to get buy in from 
abnf-interest, notably Dave Crocker.

But this should cover a multiplicity of languages. And I don't think we 
can get #include of something embedded in an RFC included in "C". 
Perhaps we need to have a rendered metadata section for sourcecode.

	Thanks,
	Paul

---

From: "John Levine" <[email-masked]>
Date: 28 Oct 2021 21:20:23 -0400

>I don't see that now. Its a bunch of names of "languages" of interest 

Quite right.  In v2, you used <artwork> to display source code, so the
v3 design invented <sourcecode> with a name and type attribute as well
as a url attribute for external source that nobody has ever used.
RFC 7991 section 2.48.4 has the initial list of types and says there
will likely be more, which in fact there are.

>I would like the list to contain references.

It is perfectly reasonable to want to do mechanical validation of some
kinds of <sourcecode> and it is not hard in principle to add new attributes
with validation hints, but if we just try to invent something we'll get it
wrong because we always do.  Come up with a design, build some tools and
see how it works, iterate until it works well.  Then we can see about adding it to V3++.
In the meantime, one of the tool options can be to strip out the new attributes or
turn them into comments so you can submit the drafts under the current grammar.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Oct 2021 03:24:10 +0200

On 2021-10-29, at 03:20, John Levine <[email-masked]> wrote:
> 
> Come up with a design, build some tools and
> see how it works, iterate until it works well.  

That’s the plan.

> Then we can see about adding it to V3++.

Can’t we simply put them into a separate XML namespace?

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 28 Oct 2021 21:33:11 -0400

> Can’t we simply put them into a separate XML namespace?

What does xml2rfc do with namespaces it doesn't recognize?  Many IDs use 
xi: for xinclude but I think that's special cased.

R's,
John

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Oct 2021 12:39:32 +1100

> xi: for xinclude but I think that's special cased.

This might depend on how strictly it applies the schema.  But it probably rejects any attempt to add something.

XML schema (and RelaxNG) both make the mistake of requiring explicit extension points in order to extend.  Kinda makes the X part of XML a joke, but there you go.  RFC 7991 (and probably the schema that xml2rfc uses) is a closed-form schema, which means that unless something is written in as permitted, it is forbidden.

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Oct 2021 12:42:35 +1100

On Fri, Oct 29, 2021, at 12:39, Martin Thomson wrote:
> This might depend on how strictly it applies the schema.  But it 
> probably rejects any attempt to add something.

There you go:

<t a:test="test" xmlns:a="test">...</t>
<a:test xmlns:a="test">test</a:test>

...: Error: Invalid attribute test for element t, at /rfc/middle/section[1]/t[1]
...: Error: Did not expect element test there, at /rfc/middle/section[1]/a:test
...: Error: Element section has extra content: test, at /rfc/middle/section[1]/a:test

eXtensible this ain't.

---

From: Jay Daley <[email-masked]>
Date: Fri, 29 Oct 2021 15:11:05 +1300

> On 29/10/2021, at 2:39 PM, Martin Thomson <[email-masked]> wrote:
> 

That’s not unusual if the goal, which it is here, is to ensure that any RFCXML document can be fully rendered in a reproducible with dependable external dependencies.

The bigger issue to my mind is that we haven’t used other namespaces enough, so that we have silly situations such as where the HTML-ised version of a pre-v3 RFC includes Dublin Core metadata but neither the XML nor HTML version of a v3 RFC do.

Jay

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Oct 2021 06:28:58 +0200

> Can’t we simply put them into a separate XML namespace?

That would be best, but would require tweaks to the grammar and
implementation.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Oct 2021 06:31:58 +0200

> The bigger issue to my mind is that we haven’t used other namespaces enough, so that we have silly situations such as where the HTML-ised version of a pre-v3 RFC includes Dublin Core metadata but n…

Dublic Core metadata, such as dates, titles, and author names? Why is
that a problem?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Oct 2021 09:24:00 +0200

Am 29.10.2021 um 07:54 schrieb Jay Daley:
>
>
>> On 29/10/2021, at 5:32 PM, Julian Reschke <[email-masked]> wrote:
>>
>>> The bigger issue to my mind is that we haven’t used other namespaces
>>> enough, so that we have silly situations such as where the HTML-ised
>>> version of a pre-v3 RFC includes Dublin Core metadata but neither the
>>> XML nor HTML version of a v3 RFC do.
>>> ...
>>
> Dublin Core doesn’t have an ‘author’ element so perhaps it’s not as
> simple as you think.
>
> Schemas such as Dublin Core serve a number of functions:
> - they standardise the data structure and allowable contents for
> specific semantic concepts
> - they provide ‘proof of meaning’ so that the reader doesn’t have to
> rely on their interpretation of a word.  In other words, if everyone
> uses DC then they use ‘creator’ instead of some using ‘author’, others
> using ‘editor ‘, etc, and us readers having to guess if they are
> equivalent.
> - they simplify machine-readability
>
> The vision Tim Berners-Lee had for open data is, in my view, still
> clearly the best direction for open data and one that we could so easily
> support given how well we do the rest of it:
>
> https://5stardata.info/en/ <https://5stardata.info/en/>

I don't argue with that.

What I was trying to understand is: do you think that any DC metadata
that we insert into the *HTML* needs to be present inside the XML source
in DC format (as opposed to "native" xml2rfc elements)?

Best regards, Julian

---

From: Jay Daley <[email-masked]>
Date: Fri, 29 Oct 2021 20:30:25 +1300

> On 29/10/2021, at 8:24 PM, Julian Reschke <[email-masked]> wrote:
> 

Sorry I misunderstood. Yes , we should not reinvent the wheel and we should make the XML the definitive source data that has all the linked data not the HTML representation. 

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

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 13:58:39 -0400

It appears that Julian Reschke  <[email-masked]> said:
>> The bigger issue to my mind is that we haven’t used other namespaces enough, so that we have silly situations such as where the HTML-ised version of
>a pre-v3 RFC includes Dublin Core metadata but neither the XML nor HTML version of a v3 RFC do.
>> ...
>

That's part of the Google Scholar problem.  Our HTML RFCs don't have the metadata they're looking for.

RFC 7992 has a list of keywords which doesn't match any list that anyone looks for.  I asked the authors
where the keywords came from and they pointed at a W3C spec which, as far as I can
tell, nobody but them ever read.

R's,
John

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Oct 2021 20:23:57 +0200

> That's part of the Google Scholar problem.  Our HTML RFCs don't have the metadata they're looking for.

I suspect that the issue is more complicated; if you do have a list of
metadata that is required I'm more than happy to run an experiment with
rfc2629.xslt, but I'm 99% sure there are also other issues involved.

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2021 14:59:49 -0400

>tell, nobody but them ever read.

For background, the HTML spec here https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-name defines
the <meta> tag and describes some standard names, so what's in RFC 7992 is utterly standard compliant.

But it turns out that over in the library community, they have their own idea about meta terms, indeed many
different ideas, many collected at https://wiki.whatwg.org/wiki/MetaExtensions, which d

Google says which keywords they look at for Google Scholar so we should add those.

R's,
John

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 30 Oct 2021 17:13:09 +0900

Hello Martin, others,

> XML schema (and RelaxNG) both make the mistake of requiring explicit extension points in order to extend.  Kinda makes the X part of XML a joke, but there you go.  RFC 7991 (and probably the schema…

It took me some time to express why the way XML Schema and RelaxNG work 
isn't a mistake. This is only tangentially relevant to this list, but it 
may help anyway.

First, the "Extensible" in "Extensible Markup Language" isn't really a 
goal of XML; see https://www.w3.org/TR/REC-xml/#sec-origin-goals. In the 
specification, the word "extensible" appears exactly three times, once 
in the title, once in the abstract, and once in the introduction. (I 
guess the IETF also has some specs where some of the words in the title 
don't exactly represent the technology.) Nevertheless, XML is definitely 
more extensible than its predecessor SGML, e.g. by requiring explicit 
end tags.

Second, the fact that both XML Schema and RelaxNG are closed by default 
is no accident. RelaxNG corrected what was considered problems in XML 
Schema, and if the closedness default would have been considered a 
problem, it surely would have been fixed.

Third, a schema language that is open by default would mean that schemas 
would allow anything anywhere; in that case, why would you need a schema 
in the first place?

Fourth, what you usually want is something else than a completely open 
schema. For example, do you allow different root elements? Probably not. 
Do you want to allow mixed content in places where the core doesn't have 
any children, just strings? Maybe in some places but not in others. And 
so on and so forth.

Fifth, allowing additional stuff is usually easier, in particular in 
RelaxNG (not totally sure about XML Schema), than prohibiting some stuff.

There are probably other reasons why having a closed default makes 
sense, and isn't a joke.

Regards,   Martin.