headers
Giovanni Tummarello | 2 Jan 2007 11:24
Picon
Gravatar

WWW2007 Workshop "I3: Identity, Identifiers, Identification" - CfP


** our apologies if you receive multiple copies of this message **

==================================================================

                       CALL FOR PAPERS

                      WWW2007 Workshop

        I3: Identity, Identifiers, Identification
       --------------------------------------------
       Entity-centric Approaches to Information and
              Knowledge Management on the Web

                Banff, Canada, May 8 2007

               http://okkam.dit.unitn.it/i3

==================================================================

The Scope
---------
Current approaches to Information and Knowledge Management (IKM) on
the Web are keyword-based, document-centric and ranking-dependent
searches: keywords are used to find and retrieve possibly long lists
of documents that are then presented in a ranked order so users will
find what they need by opening and reading through one or more
documents in the list. A substantially different yet perhaps
complementary approach to IKM on the Web is to adopt an ID-based,
entity-centric, and profile-dependent view, where information and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Carlyle | 1 Jan 2007 23:45
Picon

Re: URI and IRI Templating (What did I get myself into?)


Sorry about coming into this late, but...

Joe Gregorio wrote:
> 1. Escape all 'reserved' characters except  <at> , :, and /
>    across every component, realizing
>    we may not end up with a valid URI.
> 2. Escape all 'reserved' characters except  <at> , and :,
>    realizing that our 'path' example
>    will then break since '/' will get escaped.
> 3. Escape all 'reserved' characters except  <at> , :, and /,
>    but only allow template variables in path, query and
>    fragment components.

4. Require/allow the context to perform any necessary escaping, eg by
requiring appropiate javascript functions to have been called on the
parameter values

5. Require/allow the template to specify any necessary escaping

This specification is at an interesting point in the uri construction
chain. Normally a url to be either captured whole, or built up from
parts. Whichever part of the uri parameters are inserted into defines
the escaping that needs to occur.

http://example.com/query?a={b} where b="d&e=f" should escape "&" and "="
if b is going to be used as the value of a. If b is just a regular part
of the query component, however, escaping these characters may be
inappropriate. For example, http://example.com/query?{b} might be used
to substitute a whole query component. http://example.com{b} might be
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christopher R. Hertel | 2 Jan 2007 17:46

Re: Re: URI Scheme that needs help.

Frank Ellermann wrote:
> Christopher R. Hertel wrote:
> 
>> I could really use some help rewriting the draft
>> - to look more like a *real* IETF document,
>> - to fill in some of the gaps that are still there,
>> - to ensure compliance with existing RFCs.
> 
> Just for fun I read pages 1..8 and 15..18, and found nothing too 
> unusual.

That's good news.  Thanks.

> The concept of a workgroup context wrt to relative URLs is of course
> odd, but your description makes it clear.  Or I think it does.

The whole workgroup thing is so confusing I had to write several sections of
a book just to explain it.  I've been working with various implementations
of the SMB URI for a while.  Some get it right, others keep getting closer,
so I think I've gotten them onto the right track.

> You could add a more interesting example, where a server name exists
> in two groups, say group A with servers X and Y, and group B with
> servers Y and Z.  After doing something with smb://X/ I'd expect
> ../Y to be the Y in group A, not the Y in group B, is that correct ?

Yes and no.  If the two servers are in the same scope then they would
generate a name conflict and one of the systems would fail to register.

The reason workgroup name vs. server service name conflict *can* occur is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Schinkel | 2 Jan 2007 17:48
Picon
Gravatar

RE: URI and IRI Templating (What did I get myself into?)


Benjamin Carlyle wrote:
> In general, I think that parsing will happen on 
> actual urls rather than url templates. 

Can you give an example?  I'm not clear on your thoughts.

--

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
Permalink | Reply | 2 comments |
headers
Marc Hadley | 2 Jan 2007 20:08
Picon

Re: URI and IRI Templating (What did I get myself into?)

On Dec 26, 2006, at 5:17 PM, Mike Schinkel wrote:

>
> Mark Nottingham wrote:
>> Your proposal puts the encoding information into the variable name.
>> That's one option, but I'm reluctant to encourage putting
>> this kind of thing in there, as it encourages URI Templates
>> to become URI Schemas, and they'll quickly become unreadable.
>> Encoding is by no means the last thing we'll want to
>> associate with a particular variable.
>
> Do you mind listing off what you are thinking of in terms of other  
> things to
> associate?
>
PMFJI. A few things that occur to me are: type information (integer,  
boolean, enumerated value etc), default values, and whether an empty  
value is permissible.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
Attachment (smime.p7s): application/pkcs7-signature, 2442 bytes
Permalink | Reply | 1 comment |
headers
Marc Hadley | 2 Jan 2007 20:23
Picon

Re: URI and IRI Templating (What did I get myself into?)

Good analysis Joe, thanks.

On Dec 27, 2006, at 2:49 PM, James M Snell wrote:
>
> Ugh. I'd rather we not go down the path of embedding encoding
> information into the template.  Let's just pick a reasonable  
> default and
> leave it at that.
>
+1, Joe's "default" below looks good to me.

Marc.

> Extensions that affect the selection and validation of the replacement
> value are fine.
>
> - James
>
> Joe Gregorio wrote:
>> [snip]
>> Allow a ':' at the end of a variable name to separate out options,  
>> and then
>> add an option 'enc=<enc>'  where
>> 'enc' could be:
>>
>> enc="strict"
>>   All characters outside (iprivate | iunreserved) are % encoded
>>
>> enc="sub"
>>   Characters outside (iprivate | iunreserved | sub-delims) are %
(Continue reading)

Permalink | Reply | 21 comments |
headers
Mike Schinkel | 3 Jan 2007 04:36
Picon
Gravatar

RE: URI and IRI Templating (What did I get myself into?)


Marc Hadley wrote
> Mike Schinkel wrote:
> > Mark Nottingham wrote:
> >> Your proposal puts the encoding information into the variable name.
> >> That's one option, but I'm reluctant to encourage putting 
> this kind 
> >> of thing in there, as it encourages URI Templates to become URI 
> >> Schemas, and they'll quickly become unreadable.
> >> Encoding is by no means the last thing we'll want to 
> associate with a 
> >> particular variable.
> >
> > Do you mind listing off what you are thinking of in terms of other 
> > things to associate?
> >
> PMFJI. 

Hey, that's what mailing lists are for, right? ;-)

> A few things that occur to me are: type information 
> (integer, boolean, enumerated value etc), default values, and 
> whether an empty value is permissible.

Thank you. That helps me clarify.

--

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Schinkel | 3 Jan 2007 10:30
Picon
Gravatar

Blog post about URI Templates


Hey all:

Just thought I'd let you know I wrote about URI Templates in the WDUI Blog
today for those interested:

http://blog.welldesignedurls.org/2007/01/03/introducing-uri-templates/

--

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
Permalink | Reply | 0 comments |
headers
Benjamin Carlyle | 3 Jan 2007 11:20
Picon

RE: URI and IRI Templating (What did I get myself into?)


On Tue, 2007-01-02 at 11:48 -0500, Mike Schinkel wrote:
> Benjamin Carlyle wrote:
> > In general, I think that parsing will happen on 
> > actual urls rather than url templates. 
> Can you give an example?  I'm not clear on your thoughts.

Well... just that urls are going to be parsed. We know that. Templates
are going to be substituted. That, too, we know. I'm not sure we know
whether it will be an important use case to actually parse (as opposed
to substituting) a url template. I'm not sure that breaking up a url
template into components is going to be an important feature of the
templating scheme.

For example, we could plausibly break <http://example.com{path}?{query}>
into {http, example.com, {path}, {query}, null} components if we assume
that substitutions cannot occur over component boundaries. How useful
that in general is I think is up for debate. We will certainly need to
subtitute the variable expansions in the unparsed template. Someone
along the way is definitely going to parse the expanded
<http://example.com/the/path?the=query>, too.

I'm not sure that the parsing feature of a uri template is important
enough to limit design choices. I do think that the template should be
limited to the set permitted in a uri[1]. For example, the variable
names could be limited to the pchar set, plus "/" and maybe "?".

Benjamin
[1] or iri. I'm not someone who has come to terms with iris quite yet.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Schinkel | 3 Jan 2007 11:31
Picon
Gravatar

RE: URI and IRI Templating (What did I get myself into?)


Benjamin Carlyle wrote:
> > Benjamin Carlyle wrote:
> > > In general, I think that parsing will happen on actual 
> urls rather 
> > > than url templates.
> > Can you give an example?  I'm not clear on your thoughts.
> 
> Well... just that urls are going to be parsed. We know that. Templates
> are going to be substituted. That, too, we know. I'm not sure we know
> whether it will be an important use case to actually parse (as opposed
> to substituting) a url template. I'm not sure that breaking up a url
> template into components is going to be an important feature of the
> templating scheme.

Ah, that's much clearer now, thanks.   I agree, at least for any use cases
that interest me, I merely want to do substitutions, and most of them are
pretty simple (albiet I do often somehow manage to grow the complexity of
things when I dive down into the. ;)

--

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
Permalink | Reply | 0 comments |

Gmane