W3C home > Mailing lists > Public > public-poiwg@w3.org > September 2011

Re: a note on links

From: Raj Singh <rsingh@opengeospatial.org>
Date: Wed, 28 Sep 2011 20:25:51 -0400
Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
Message-Id: <CB49B032-EA85-4114-BDFE-4A195D2C05D1@opengeospatial.org>
To: roBman@mob-labs.com
I like it. I think we're converging on violent agreement here!
---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact


On Sep 28, at 7:01 PM, Rob Manson wrote:

> Hey Raj,
> 
> nice concise feedback in your previous email...thanks 8)
> 
> As for the link model...my goal in the top section of the examples page
> was to show how many of these things could be handled in 3 ways.  Let's
> take author as an example.
> 
> 1. omit it
> I don't think this would be a required field so a POI publisher could
> choose to drop this field if they wanted to.
> 
> 2. link it
> If the POI publisher wants to refer to the author but doesn't think it's
> important to inline it then they could provide an implicit link.
> In json this would be...
> 
>        {
>          ...
>          author:"http://mob-labs.com/poiwg/example02/pois/",
>          ...
>        }
> 
> In xml this would be ...
> 
>        <pois href="http://mob-labs.com/poiwg/example02/pois.xml" xml:lang="en">
>          ...
>          <author href="http://mob-labs.com/poiwg/example02/robman" />
>          ...
>        </pois>
> 
> NOTE: Now that I look at the example I actually included I had only put
> an email address.  This is misleading so I've updated that in the draft
> example02.
> 
> 3. inline it
> If the POI publisher thinks it's important for this information to be
> serialised inline then they can also do that - effectively unfolding the
> link.  I used the atom:author params but I agree with you that
> vcard/hcard may be a better data structure.
> In json this would be...
> 
>        {
>          ...
>          author:{
>                   name:"", <- atom:name
>                   email:"", <- atom:email
>                   href:"" <- atom:uri
>                 },
>          ...
>        }
> 
> In xml this would be...
> 
>        <pois href="http://mob-labs.com/poiwg/example02/pois.xml" xml:lang="en">
>          ...
>          <author href="http://mob-labs.com/poiwg/example02/robman">  <- href/link is optional
>            <name>Rob Manson</name>
>            <email>roBman@mob-labs.com</email>
>          </author>
>          ...
>        </pois>
> 
> In html5 this would be...
> 
>        <span>
>          ...inline author microdata goes here...
>          <link itemprop="author" href="http://mob-labs.com/poiwg/example02/robman">
>        </span>
> 
> NOTE: I've updated the uri field to be href as the intent here was that
> this optional field could then also act like the link approach in point
> 2. above.  So if this field is not included then only the serialised
> information about the author is known.  But if href/link is included
> then we would also know what the authoritative source for info about
> this author is.
> 
> I think there are a number of levels within the POI data model that
> would really benefit from these 3 options of omit/link/inline.
> 
> So my goal is not to enforce the use of link...but allow it as one valid
> approach.  And allowing link's to optionally embed extra info like
> rights, version-history, etc. means that these things can be injected at
> many levels (e.g. pois, poi or specific fields) at the POI publishers
> discretion.
> 
> Update draft is here: http://mob-labs.com/poiwg/example02/index.html 
> 
> roBman
> 
> 
> On Wed, 2011-09-28 at 08:47 -0400, Raj Singh wrote:
>> In the last F2F we talked a lot about using the HTML5 link tag as much
>> as possible. We tried to shoehorn many concepts into link. After
>> further thought, I want to back off this approach. 
>> 
>> HTML5 links never have inline content. We want that option. And their
>> meaning and usage is different than ours. For example, we want to
>> inline author information sometimes. Using a "link" object and
>> actually defining what it really is with the link's "rel" attribute
>> does adds an unnecessary level of complexity with no real benefit to
>> developers or users as the relationship between HTML5 links and our
>> idea of links is weak. 
>> 
>> I propose instead to name elements what we want them to be -- e.g.
>> "author" -- and have global attributes that can appear on all these
>> elements such as "href" and "type" (and "lang" and "updated").
>> 
>> ---
>> Raj
>> The OGC: Making location count...
>> http://www.opengeospatial.org/contact
>> 
>> 
>> 
>> 
> 
> 
Received on Thursday, 29 September 2011 00:26:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:22 UTC