Re: Poll: Relative URIs and Strings in xmlns attributes

I guess I'm looking this issue from the language standard viewpoint...

- "undefined" means that compilers will accept it, but what happens when
you do it will vary between compilers

- "error" means that you can't do it, the compiler won't let you

The language standards I'm familiar with clearly distinguish between these
two cases, and use "undefined" not infrequently.

Compilers typically do something useful for the "undefined" cases, but if
you want your code to be portable you just won't do those things.

-Mark Bartel
JetForm Corporation

-----Original Message-----
From: "Joseph M. Reagle Jr." <>
Sent: Thu, 21 Sep 2000 14:30:02 -0400
To: "Gregor Karlinger" <>
Subject: Re: AW: Poll: Relative URIs and Strings in xmlns attributes

At 10:35 9/21/2000 +0200, Gregor Karlinger wrote:
>My way of thinking is that an algorithm performing Canonical XML must return
>an error if it dedects relative URIs in the input. Maybe I am wrong, Joseph?

My intent was to think that there would be an error. However, I hadn't 
considered the idea of saying there is a canonical form, it just won't 
necessarily be consistent/interoperable. This sounds like a reasonable 
interpretation of the plenary decision, but then it seems we aren't doing 
anyone a favor. If we're going to "permit" relative URIs when we should be 
encouraging their deprecation, at least we should do it consistently...?

(More later).

BTW: I understand our treatment of this issue was briefly discussed at the 
XML Plenary this week with the following two sorts of positions

>...the issue of the c14n spec defining a canonical form for
>         <aDoc xmlns="../foo"/>
>         - it's against the plenary decision
>                 (from Michael Sperberg-McQueen, among others)
>         - it seems reasonable, even given the plenary decision
>                 (from Noah Mendelsohn, among others)

Joseph Reagle Jr.
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair

Received on Thursday, 21 September 2000 14:57:38 UTC