← Prev in month ← Prev in thread
Next in thread → Next in month →

Forwarding from Phil: Is it a problem that the XDI # symbol will conflict with URI # fragment char?

From
=Drummond Reed <>
Date
2014-03-05T02:10:27+00:00
ID
CAAjunnbn9V1M2PZZt2fPo0H4dX5B9rFspo2QM76ds4YmpUz=
Thread
Forwarding from Phil: Is it a problem that the XDI # symbol will conflict with URI # fragment char?
Phil was not sure if this message reached the list.

---------- Forwarded message ----------
From: Phil Windley <>

Date: Tue, Mar 4, 2014 at 4:33 PM
Subject: Re: Is it a problem that the XDI # symbol will conflict with URI # fragment char?
To: =Drummond Reed <>, OASIS - XDI TC <>, Drummond Reed <>

Not by me. I’ve long felt that the perceived need to keep XDI statements within the URL syntax was a significant source of notational complexity and contributed to XDI’s contorted syntax. I understand the need for the 5 or 6 years ago. I think that need has diminished greatly and XDI could be made more readable by dropping the idea the XDI statements need to be erodible as URLs altogether. 

 

 

From: =Drummond Reed 

Reply: =Drummond Reed 
Date: March 4, 2014 at 5:18:50 PM
To: OASIS - XDI TC 

Subject:  Is it a problem that the XDI # symbol will conflict with URI # fragment char? 

 

As part of coming to a final decision about The
Great Symbol Swap, I just had a long talk with Peter about his -1
vote. His primary concern is one I share: as attractive as # might
be as the popular symbol for a hashtag—and thus generally
applicable to the XDI dictionary space—it is also the URL fragment
identifier.

This means that when it is typed in a URL, the browser does
not send it to the server, but only processes it locally in
parsing the returned resource.

So if we expect users to type #words (unescaped) as part of an
XDI address into a browser address bar (without a plug-in), they
will not be part of the XDI address sent to the server.

This is not a problem if we assume some form of XDI-aware
smart client will be used to resolve XDI addresses (e.g., a browser
plug-in, a web form submitted to an XDI resolver, a mobile app,
etc.), as then all XDI addresses will be automatically
URL-encoded.

So, I cast this question out to TC members: is this a problem
you are concerned about or not?

=Drummond

On Tue, Mar 4, 2014 at 5:22 AM, Davis,
Peter <> wrote:

-1. 

I remain concerned that we are just relocating the semantic
collision from @ to # (both have meanings to the general population
outside of XDI).

=peterd

On Mar 4, 2014, at 03:06 AM, Markus Sabadello <> wrote:

+1

On Tue, Mar 4, 2014 at 8:46 AM, =Drummond
Reed <> wrote:

Per the minutes I just sent out, I have continued to
check with both XDI TC members and others involved in
related infrastructure with the following results:

There is unanimous support for reassigning + to the
legal/business authority namespace (formerly represented by
@).

There is nearly unanimous support for reassigning # to the
dictionary namespace (formerly represented by +) and
reassigning @ to the ordered collection member namespace (formerly
represented by #).

So this is a call for rough consensus, i.e.:

If you agree with the proposed reassignments in the two bullet
points above, reply with a +1.

If you are neutral, reply with a 0 (or don't reply).

If you disagree with these proposed reassignments, reply
with a -1.

Thanks,

=Drummond  

Peter Davis: Neustar, Inc.

Distinguished
Engineer, Director, Neustar Foundry

45980 Center Oak Plaza Sterling,
VA 20166

[T] +1 571 434 5516 [E]  [W] http://www.neustar.biz/ [X]
xri://@neustar*pdavis [X]
xri://=peterd

The information contained in this e-mail
message is intended only for the use of the recipient(s) named
above and may contain confidential and/or privileged information.
If you are not the intended recipient you have received this e-mail
message in error and any review, dissemination, distribution, or
copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately
and delete the original message.
← Prev in month ← Prev in thread
Next in thread → Next in month →