[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments: draft-hollenbeck-ietf-xml-guidelines-00.txt
At 09:00 PM 4/9/02 -0400, Hollenbeck, Scott wrote:
> 3. Section 3 talks about internationalization. I think a
> reference to
> [charmod] would be in order:
> <http://www.w3.org/TR/charmod/>. Hopefully,
> it will be stable by the time this draft makes BCP.
Is there a specific section that you have in mind? The charmod WD provides
"a common reference for interoperable text manipulation on the World Wide
Web"; what portion of the WD might be applicable to the text encoding
That was before I'd read the later sections. I don't think more is needed
> 6. Section 4.7: Also mention data: URL: ??
I'm not sure I understand - can you suggest additional text?
Hmm... I'm not claiming this is a Good Idea, just something to
consider. Add one more paragraph to section 4.7:
Another way to include modest amounts of binary data in an XML document
might be to use a data: URL with base64 encoding; e.g. (adapted from RFC 2397):
This approach might be usable with protocols like APEX [x] that have in
their design a provision for either inline XML content or a URI reference
to external content. A data: URL could be an alternative to (say) a cid:
URL referencing another part of a multipart/related MIME structure.
> 7. Section 5. Also reference [charmod] here?
Again, is there a particular section of the WD that fits into the flow of
this section, and/or how would you suggest weaving in a reference?
OK. Either an addition to section 5.1, or a new sub-section in section
5. I don't really understand this stuff very well, but am aware that there
are some tricky issues that I believe are being addressed by the [charmod]
work. But I imagine something like:
There are a number of tricky issues that can arise when using extended
character sets with XML document formats:
- there are different ways of representing characters consisting of
- there has been some debate about whether URIs should be represented using
a restricted US-ASCII subset or arbitrary Unicode (c.f. "URI character
sequence" vs "original character sequence" in RFC 2396).
Some of these issues are discussed, with recommendations, in [charmod].
I'm sorry this isn't really adequate as suggested text, but I hope it
points to the kinds of issue I'm suggesting might be mentioned.