- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Wed, 28 Sep 2011 20:25:51 -0400
- To: roBman@mob-labs.com
- Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
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