Hello Mark,
I have just responded in quite some detail to Robert, which should cover quite some of your questions.
At 09:25 05/01/30, Mark Nottingham wrote:
>
>As I understand it, if I implement an Atom processor that doesn't support IRIs, It's not conformant, and will have problems with some valid feeds, when dereferencing IRIs.
Yes and no. Does the Atom spec require that an Atom processor support http? Maybe it does. Does it require that any other uri scheme/protocol is supported? I think it doesn't. Does it require that all http uris always resolve? No, it just can't, because of network reality. So I guess there is some slack for some implementations, although of course we wouldn't like them to use that slack.
I also think that testing is quite important. If somebody could point to some basic Atom tests, I'll try to set up some equivalent tests that use IRIs. For browsers, even a single test that I put up some years ago lead to a lot of improvement.
>So, if we require support, it's potentially setting a higher bar for implementations. It wouldn't be a big deal to require IRIs if support were available in most languages that people are likely to use Atom in; e.g., Perl, Python, C#, Java, ECMAScript, VB, Ruby, etc.; preferably in their standard libraries, but at least in a single download.
>
>Martin, do you know when can we expect to see such things appear? I've seen a few suggestions for Java go by, but not much else.
I have up to now concentrated on pushing browser support, so I haven't spent that much time looking at library/language support, but I think it's very important, and any information (such as just even a list of languages like above) is highly appreciated. Also, if you can point to any specific libraries, we can look at these libraries and look at how to integrate IRIs. As I have written in my mail to Robert, in terms of actual code, it's not a really a big deal. Also, as far as I understand, most of the above languages allow integration of C code, so it's mostly a question of integration.
In addition to that, the Unicode support in these languages is varying, and in some cases developping. For example for Perl, there is quite some differences e.g. between 5.0x, 5.6x, and 5.8x. Of course, to correctly implement Atom, appropriate Unicode support is needed. In many ways, Unicode support is 90% of IRI support.
Also, I'm quite sure that using IRIs in Atom will be a great motivation for various library maintainers.
I have already contacted the perl Unicode list yesterday (after some naive attempts of mine to use some Perl modules failed) and already got some initial responses. I'll update this list once I know more.
>Also, has anyone identified which uses of URIs in Atom are likely to pose problems when converted to IRIs? Some URIs in Atom are used as identifiers, and not dereferenced. In those cases, my (possibly naive) inclination would be that as long as they're compared character-by-character, making them IRIs wouldn't be an issue, and we could use IRIs for at least some things in Atom (e.g., id, but not link) no matter what the status of library implementations.
This is not a naive assumption. In fact, although XML Namespaces 1.0 says that namespaces identifiers are URIs (namespaces 1.1 extends this to IRIs), the vast majority of XSLT implementations work without any problems on input that uses IRIs in namespace URIs.
But the fact that we get IRI support for IDs for free, whereas IRI dereferencing will require some work, should not mean we only do the former and not the later. Although IRI dereferencing requires some work, that work isn't very much work, even if not relying on libraries. Also, I wouldn't expect users to understand why they could use IRIs in some places and not in others.
Regards, Martin.
