Address isomorphic string and ByteString guidance #158
Conversation
Fixes w3c#151 Adds a new subsection about byte-oriented formats. Adds guidance about ByteString and isomorphic strings. Moves the guidance about not defining legancy encoding to the encoding section.
✅ Deploy Preview for bp-i18n-specdev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@annevk Mentioning you for a potential review. I'm working here to make the last bits of consistency with https://www.w3.org/TR/design-principles/#idl-string-types especially your comment here |
index.html
Outdated
| <p>See also <a href="#char_choosing"></a>.</p> | ||
| </details> | ||
| </div> | ||
| <p>{{ByteString}} isn’t a general-purpose string type. The type {{ByteString}} defines strings as sequences of bytes (octets). Interpretation of byte strings thus requires the specification of a [=character encoding form=]. UTF-8 is the preferred encoding for wire and document formats on the Web [[ENCODING]] or the Internet in general [[RFC3629]]. If the field is encoded in UTF-8, there is rarely a reason to interact with it as a byte sequence.</p> |
There was a problem hiding this comment.
This is still confusing. A ByteString maps to an isomorphic string. There's no choice of encoding.
There was a problem hiding this comment.
This is a good callout. I tried to stick to the text in design principles, WebIDL and INFRA, but have to admit that the text there is fairly mysterious. I've refried this section again. See what you think. Suggestions welcome.
- define 'byte string' - quote HTTP RFC 9112 - rewrite guidance
index.html
Outdated
|
|
||
| <p>It is preferable, however, to specify these fields as a {{DOMString}} (or, rarely, a {{USVString}}), since the data encoded into these fields must be serialized from and deserialized into in-memory string representations, such as the [[DOM]] or JavaScript strings or your platform's native Unicode string type.</p> | ||
| </aside> | ||
| <p>{{ByteString}} isn’t a general-purpose string type. Frequently processing of these will be done by performing an [=isomorphic decode=] of the {{ByteString}} into an [=isomorphic string=] or by performing an [=isomorphic encode=] of such a string back into bytes [[INFRA]]. (It is also possible that the specification with work with the bytes directly.)</p> |
There was a problem hiding this comment.
Per Web IDL a ByteString always maps to an isomorphic string. I suppose it's true that unusual processing might take place, but in all cases I can recall we leave it at that. And unusual processing might take place for all string types, but we're not calling that out either so it seems weird to treat this type so circumspect.
index.html
Outdated
| </aside> | ||
| <p>{{ByteString}} isn’t a general-purpose string type. Frequently processing of these will be done by performing an [=isomorphic decode=] of the {{ByteString}} into an [=isomorphic string=] or by performing an [=isomorphic encode=] of such a string back into bytes [[INFRA]]. (It is also possible that the specification with work with the bytes directly.)</p> | ||
|
|
||
| <p>{{ByteString}} should not be confused with the more general term [=byte string=].</p> |
There was a problem hiding this comment.
I would rather no specification would be able to use a term like "byte string". That does seem like it could lead to confusion.
Fixes #151
Adds a new subsection about byte-oriented formats. Adds guidance about ByteString and isomorphic strings. Moves the guidance about not defining legacy encoding to the encoding section.
Preview | Diff