<div dir="ltr">Hi Jeff<div><br></div><div>Please see my proposal of MarkedComponent <<a href="http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html">http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2014-September/000085.html</a>>, which is a solution to eliminate ambiguity by defining a new type specifically for key-value pair.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 8:18 AM, Burke, Jeff <span dir="ltr"><<a href="mailto:jburke@remap.ucla.edu" target="_blank">jburke@remap.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Second, if the most important issue is eliminating ambiguity/aliasing,<br>
then why not define a new type that hints that the component can be<br>
interpreted as a key/value pair with some encoding convention?  This could<br>
enable an unambiguous, short list of commonly used conventions that you've<br>
mentioned (using marker-like keys),  while keeping information describing<br>
the data object in the name. It would also be very useful for applications<br>
that desire their own k/v representation for components, which Dave has<br>
argued for in other circumstances and we keep running across. It doesn't<br>
rule out use of hierarchy, and doesn't limit what an application defined<br>
keys could be.  Yet, it could be ignored in forwarding (just another<br>
component) and perhaps have a still-meaningful sort order (key, then<br>
value).<br><div class=""><div class="h5"><br></div></div></blockquote></div></div></div></div>