RE: NFC and RDF Security consideration

<advocacy>
I have been disappointed at the response to my examples.

For me, the reason for having a textual rather than a binary representation for RDF graphs is so that the textual form can be looked at and understood (correctly).

Examples include debugging.
Examples also include document authoring and understanding prior to the availability of appropriate tools.

Appropriate tools for non-US users will be a longer time coming than those for US users (probably).

We have obligations to potential RDF users world wide.

If we are not serious about supporting the use of non-US ASCII characters within RDF/XML then why are they allowed? Why isn't RDF/XML a binary syntax, or a US-ASCII only syntax?

RDF syntax is built on XML syntax and URI syntax.
Both of these have the ability of being written down, and some level of human comprehensibility as explicit goals.

Both of these are being reviewed in the light of a better understanding of Unicode.

Charmod reflects the current wisdom of the unicode community; and, for us, amounts to, when using unicode strings as identifiers within some formal language it is necessary to define the normalization form used, and NFC is preferred.

My examples show why.

I think we should:
- require RDF literals to be in NFC
- use original character sequences for URIs within RDF and require these to be in NFC (that isn't intended to rule out the use of the % escaped forms, merely to say that they are different identifiers).

I think these two steps will significantly clarify how RDF can be used world wide, and make good on various ToDo's within M&S.

</advocacy>

Received on Tuesday, 12 March 2002 07:26:57 UTC