Closed ronaldtse closed 2 years ago
@strogonoff your opinion here please?
@ronaldtse I’d say if those are proper anchors, then they should remain so… But whether it is the correct shape for an anchor I’m not sure due to lack of familiarity with IANA standards.
As far as BibXML service’s XML output is concerned, I believe IETF mentioned that anchor value may have to escape special characters. That could be done on the fly in XML serializer.
Thanks @strogonoff . Given that these anchors are used directly in XML as identifiers, we should just replace them with underscores or hyphens. Hyphens are commonly used in the names of IANA registries, so let's use underscores instead.
Underscores are used in several items like: https://github.com/ietf-ribose/relaton-data-iana/blob/3b2cda1a0d184c19b74c8f296d74ee2a46ef85cb/data/_6lowpan-parameters.yaml
But they are rare.
@andrew2net can we replace /
with __
(two underscores)?
@ronaldtse I suspect this particular case has to do with XML output, and should be handled on the fly by BibXML service. It’s a quick change I can make right now.
In other words, unless I am mistaken, replacing slashes in source data would impact semantics not in the right way. (If I am mistaken, let me know…)
@andrew2net can we replace
/
with__
(two underscores)?
@ronaldtse sure we can. Suppose we need to make the replacement in anchor only, don't we?
Please wait with replacement in YAML until Ronald clarifies regarding my comment above. This may not be source data concern but serialization concern.
Suppose we need to make the replacement in anchor only, don't we?
Yes. Replacement in the anchor only. I also want to replace the "type: IANA" with "type: IETF" because it is an IETF request (IANA and IETF belong to the same top-level entity, and that all IANA registries are created by the IETF).
I suspect this particular case has to do with XML output, and should be handled on the fly by BibXML service. It’s a quick change I can make right now. replacing slashes in source data would impact semantics not in the right way.
It is a semantic change, so changing in the data is fine. The only people that use "anchors" are IETF users of BibXML.
Furthermore, this will not break backwards compatibility because the data for "IANA sub-registries" was never available until we made them available.
OK, if you say this is a semantically intended change then we can proceed. It just struck me as a presentational change to accommodate XML/schema limitations at first.
I'm not sure about these: https://github.com/ietf-ribose/relaton-data-iana/blob/3b2cda1a0d184c19b74c8f296d74ee2a46ef85cb/data/ace_ace-profiles.yaml#L14-L16
https://github.com/ietf-ribose/relaton-data-iana/blob/3b2cda1a0d184c19b74c8f296d74ee2a46ef85cb/data/dns-parameters_zonemd-schemes.yaml#L14-L16
I don't think the anchor can contain
/
. Maybe we change them to.
?Originally posted by @ronaldtse in https://github.com/relaton/relaton-iana/issues/5#issuecomment-1075518754