Explain why plain name fragments are as they are #1293
Conversation
|
Right now, the spec is quite bloated with things that don't necessarily belong in a specification. Mostly I think that's because we didn't really have anywhere else to put things, but that's not the case anymore. This strikes me as maybe something that should be a blog post or maybe an ADR. |
|
@jdesrosiers I could see it as an ADR. I don't think it's actually interesting enough for a blog post. I've been thinking of writing ADRs for some decisions that people still ask about just to document them. Although sometimes trying to make it fit the ADR format when I can't even remember what the alternatives were is a bit annoying. |
Because XML is/was the most likely need for cross-media-type fragment identifiers.
In response to PR review feedback, remove the editorial explanation and instead consolidate the fragment syntax in the section on fragments. The context and reason for the syntax is more clear there with the existing text, and one additional line further clarifies it by not just seeming to reference a random XML syntax rule for no clear reason.
handrews
force-pushed
the
plain-name-frags
branch
from
8bd7f2c to
f367d47
Compare
"these keywords" for both "$anchor" and "$dynamicAnchor"
|
@jdesrosiers I considered making this an ADR, but it doesn't fit the format well because we kind of inherited this and assembled our own justifications for keeping it. There wasn't really a clear decision point. I also noticed that it's weird that the Fragment Identifiers section doesn't actually define the plain name syntax, which instead appears in the section of So I've removed the editorial explanation about XML and APIs, moved the syntax up to the Fragment Identifiers section, and added one extra line so that the reason for using NCName is clear. Given the bewildering constellation of XML specifications, the additional link is, I think, useful as an informative reference. But I'm open to counter-arguments. |
gregsdennis
added
clarification
Because XML is/was the most likely need for cross-media-type fragment identifiers.
Fixes #901