Re: Resources and presentation views

itai dor-on <[email protected]> Thu, 8 May 2014 00:00:58 -0700 (PDT)
Newsgroups gmane.comp.web.services.rest
Message-ID <[email protected]>
---1593584224-1419688989-1399532458=:57409
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Thanks for the clear explanations!
I often feel challenged when attempting =
to apply REST concepts
in my design not because of REST per se but rather h=
ow to implement the model while being
aligned with HTTP requirements. The t=
hing is that HTTP does not link back to
REST :) meaning some of the RFC req=
uirements are phrased in such ways that
raise dilemmas =E2=80=93 for exampl=
e consider the following note on POST:
=E2=80=9CThe action performed by the=
 POST method might not result in
a resource that can be identified by a URI=
.=E2=80=9D
Such sentence automatically=C2=A0raises me several questions:
=
=E2=80=9CCan a POST operation successfully result in=C2=A0creating=C2=A0a R=
esource that is not identified
by a URI? What does this mean in the context=
 of REST? Why they don=E2=80=99t just say
=E2=80=9CThe action performed by =
the POST method might not result in a resource=E2=80=9D? =E2=80=9CIs there
=
a notion here of a =E2=80=9Chidden resource=E2=80=9D (e.g non-addressable).=


Or 
=E2=80=9CIf a resource has been created on the origin server, the
resp=
onse SHOULD be 201 (Created) and contain an entity which describes the
stat=
us of the request=E2=80=9D (SHOULD as in:
know what the heck you=E2=80=99re=
 doing before you decide)
What if more than one resource was created on the=
 server
like in my initial example where the Report Views where created imp=
licitly as
part of posting a Report entity?, What if I just want to use the=
 Report as a
scoping identifier and not represent it =C2=A0as an addressabl=
e resource but only it=E2=80=99s views
resources? 
(I accept your suggestio=
n above, but just for the sake of the example) Should I
consider the Posted=
 entity simply as a =E2=80=9CRequest to create a Report and its
dependent r=
esources=E2=80=9D as opposed to as independent Report entity? If the
creati=
on one of the sub resources fails how should I report that to the client?
S=
hould I look at the whole processes as one server transaction that=E2=80=99=
s hidden
from the client? Does it make any difference=C2=A0if a
parent reso=
urce was created on one server and=C2=A0a child on a different server?
Shou=
ld I propagate=C2=A0a=C2=A0remote server error response back to the client
=
or should I mask it=C2=A0at the server which initially received the request=
 by creating a new =E2=80=9Csummary
error response=E2=80=9D?
I wish there w=
as a book =E2=80=9CREST Scenarios=E2=80=9D that would teach
REST by using H=
TTP as vehicle for describing different implementations and
explain where H=
TTP requirements can be relaxed and why while still being RESTful. I=E2=80=
=99m fully aware that
REST is independent from HTTP but for all practical p=
urposes, nowadays, HTTP is
probably the most relevant for doing REST.
-M
On=
 Thursday, May 8, 2014 2:07 AM, Erik Wilde <[email protected]> wrote:
  
=
=C2=A0 
hello m.


On 2014-05-07, 10:22 , [email protected] wrote:
> 1.How=
 does REST treat the notion of alternate presentation views for
> resource =
instances?
> For example suppose you want to model various views of a =E2=
=80=9CReport=E2=80=9D such
> as =E2=80=9CPie Chart=E2=80=9D / =E2=80=9CHist=
ogram=E2=80=9D .. that all share a common media type
> (text/html). How wou=
ld such scenario be implemented using HTTP in
> RESTful way?


have a report=
 resource that contains types links to the various views, 
which are resour=
ces themselves. this allows clients to link to those 
views, or to link to =
the more abstract general report. also, if 
possible, include backlinks fro=
m the views, so that a client accessing a 
view can find the general report=
 resource.


> 2.Are resources required to expose a public URL or can they b=
e thought
> of conceptually part of other resources Value Set without any U=
RL?
> For example suppose that all Report views are modeled as dependent
> =
resource that are implicitly created when the client POSTS a Report to a
> =
Reports Collection, is there any requirement to maintain a URL for the
> Re=
port resource instance itself such as /Reports/1 (assuming all access
> is =
limited through views) What would be a proper response to such HTTP
> POST =
?
> /Reports/1/PieChart
> /Reports/1/Histogram


you could make /Reports a "=
POST-only" resource, but i'd suggest to keep 
/Reports/1 around because


- =
it's a convenient starting place to find all view links
- it allows you to =
DELETE an entire report
- it may also link to or contain additional info su=
ch as a history or 
whatever else may be interesting about a report apart f=
rom the views


> 3.According to the URL RFC 3986 different query strings pr=
oduce
> different resource identifiers, is there any advantage to model
> a=
lternate view resources using path components over query parameters or
> vi=
ce versa, (seems like same thing) ?


it's similar and to some extent, query=
 strings are a historical aspect 
of URI syntax. usually, people use paths =
when resource structure and 
navigation is clearly hierarchical (and then b=
eing able to "hack" URIs 
in the address bar can be very convenient), and q=
uery strings are used 
when things get more complicated, such as multiple d=
imensions of how 
resources are related. that being said, keep in mind that=
 good REST 
designs should not depend on specific URI patterns anyway, you =
should 
have a logical view of how you interlink resources. using "pretty U=
RIs" 
then makes your service nicer to use, but your design should work in =
the 
very same way, regardless of whether you use /Reports/1/pie or 
/Repor=
ts/1?view=3Dpie


cheers,


d.


-- 
erik wilde | mailto:[email protected]  - =
 tel:+1-510-2061079 |
| UC Berkeley  -  School of Information (ISchool) |
|=
 http://dret.net/netdret http://twitter.com/dret |
  
 
---1593584224-1419688989-1399532458=:57409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html>
<head>
</head>






=20
<body style=3D"background-color: #fff;">
<span style=3D"display:none">&nbsp;</span>

<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id=3D"ygrp-mlmsg" style=3D"position:relative;">
  <div id=3D"ygrp-msg" style=3D"z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->

    <div id=3D"ygrp-text" >
=20=20=20=20=20=20
=20=20=20=20=20=20
      <p><div style=3D"color:#000;background-color:#fff;font-family:Helveti=
caNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-si=
ze:12pt;"><div></div><span><div><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">Th=
anks for the clear explanations!</font></div><div><font face=3D"Times New R=
oman">



</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">I =
often feel challenged when attempting to apply REST concepts
in my design not because of REST per se but rather how to implement the mod=
el while being
aligned with HTTP requirements. The thing is that HTTP does not link back t=
o
REST :) meaning some of the RFC requirements are phrased in such ways that
raise dilemmas =E2=80=93 for example consider the following note on POST:</=
font></div><div><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">=
=E2=80=9CThe action performed by the POST method might not result in
a resource that can be identified by a URI.=E2=80=9D</font></div><div><font=
 face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">Su=
ch sentence automatically&nbsp;raises me several questions:
=E2=80=9CCan a POST operation <span style=3D"font-size: 11pt;">successfully=
 </span>result in&nbsp;creating&nbsp;a Resource that is not identified
by a URI? What does this mean in the context of REST? Why they don=E2=80=99=
t just say
=E2=80=9CThe action performed by the POST method might not result in a reso=
urce=E2=80=9D? =E2=80=9CIs there
a notion here of a =E2=80=9Chidden resource=E2=80=9D (e.g non-addressable).=
</font></div><div><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">Or=
 </font></div><div><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">=
=E2=80=9CIf a resource has been created on the origin server, the
response SHOULD be 201 (Created) and contain an entity which describes the
status of the request=E2=80=9D (SHOULD as in:
know what the heck you=E2=80=99re doing before you decide)</font></div><div=
><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">Wh=
at if more than one resource was created on the server
like in my initial example where the Report Views where created implicitly =
as
part of posting a Report entity?, What if I just want to use the Report as =
a
scoping identifier and not represent it <span>&nbsp;</span>as an addressabl=
e resource but only it=E2=80=99s views
resources? <br>
(I accept your suggestion above, but just for the sake of the example) Shou=
ld I
consider the Posted entity simply as a =E2=80=9CRequest to create a Report =
and its
dependent resources=E2=80=9D as opposed to as independent Report entity? If=
 the
creation one of the sub resources fails how should I report that to the cli=
ent?
Should I look at the whole processes as one server transaction that=E2=80=
=99s hidden
from the client? Does it make any difference&nbsp;if a
parent resource was created on one server and&nbsp;a child on a different s=
erver?
Should I propagate&nbsp;a&nbsp;remote server error response back to the cli=
ent
or should I mask it&nbsp;at the server which initially received the request=
 by creating a new =E2=80=9Csummary
error response=E2=80=9D?</font></div><div><font face=3D"Times New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">I =
wish there was a book =E2=80=9CREST Scenarios=E2=80=9D that would teach
REST by using HTTP as vehicle for describing different implementations and
explain where HTTP requirements can be relaxed and why while still being RE=
STful. I=E2=80=99m fully aware that
REST is independent from HTTP but for all practical purposes, nowadays, HTT=
P is
probably the most relevant for doing REST.</font></div><div><font face=3D"T=
imes New Roman">


</font></div><div style=3D"margin: 0in 0in 10pt;"><font face=3D"Calibri">-M=
</font></div><div><font face=3D"Times New Roman">


</font></div></span><div></div><div class=3D"yahoo_quoted"> <div style=3D"f=
ont-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande,=
 sans-serif;font-size: 12pt;"> <div style=3D"font-family: HelveticaNeue, He=
lvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size: 12pt;"=
> <div dir=3D"ltr"> <font face=3D"Arial" size=3D"2"> On Thursday, May 8, 20=
14 2:07 AM, Erik Wilde &lt;[email protected]&gt; wrote:<br> </font> </div> =
 <div><div id=3D"yiv0925342483"><div>
<span>&nbsp;</span>




<div id=3D"yiv0925342483ygrp-mlmsg">
  <div id=3D"yiv0925342483ygrp-msg">




    <div id=3D"yiv0925342483ygrp-text">
=20=20=20=20=20=20
=20=20=20=20=20=20
      <div>hello m.<br clear=3D"none">
<br clear=3D"none">
On 2014-05-07, 10:22 , [email protected] wrote:<br clear=3D"none">
&gt; 1.How does REST treat the notion of alternate presentation views for<b=
r clear=3D"none">
&gt; resource instances?<br clear=3D"none">
&gt; For example suppose you want to model various views of a =E2=80=9CRepo=
rt=E2=80=9D such<br clear=3D"none">
&gt; as =E2=80=9CPie Chart=E2=80=9D / =E2=80=9CHistogram=E2=80=9D .. that a=
ll share a common media type<br clear=3D"none">
&gt; (text/html). How would such scenario be implemented using HTTP in<br c=
lear=3D"none">
&gt; RESTful way?<br clear=3D"none">
<br clear=3D"none">
have a report resource that contains types links to the various views, <br =
clear=3D"none">
which are resources themselves. this allows clients to link to those <br cl=
ear=3D"none">
views, or to link to the more abstract general report. also, if <br clear=
=3D"none">
possible, include backlinks from the views, so that a client accessing a <b=
r clear=3D"none">
view can find the general report resource.<br clear=3D"none">
<br clear=3D"none">
&gt; 2.Are resources required to expose a public URL or can they be thought=
<br clear=3D"none">
&gt; of conceptually part of other resources Value Set without any URL?<br =
clear=3D"none">
&gt; For example suppose that all Report views are modeled as dependent<br =
clear=3D"none">
&gt; resource that are implicitly created when the client POSTS a Report to=
 a<br clear=3D"none">
&gt; Reports Collection, is there any requirement to maintain a URL for the=
<br clear=3D"none">
&gt; Report resource instance itself such as /Reports/1 (assuming all acces=
s<br clear=3D"none">
&gt; is limited through views) What would be a proper response to such HTTP=
<br clear=3D"none">
&gt; POST ?<br clear=3D"none">
&gt; /Reports/1/PieChart<br clear=3D"none">
&gt; /Reports/1/Histogram<br clear=3D"none">
<br clear=3D"none">
you could make /Reports a "POST-only" resource, but i'd suggest to keep <br=
 clear=3D"none">
/Reports/1 around because<br clear=3D"none">
<br clear=3D"none">
- it's a convenient starting place to find all view links<br clear=3D"none"=
>
- it allows you to DELETE an entire report<br clear=3D"none">
- it may also link to or contain additional info such as a history or <br c=
lear=3D"none">
whatever else may be interesting about a report apart from the views<br cle=
ar=3D"none">
<br clear=3D"none">
&gt; 3.According to the URL RFC 3986 different query strings produce<br cle=
ar=3D"none">
&gt; different resource identifiers, is there any advantage to model<br cle=
ar=3D"none">
&gt; alternate view resources using path components over query parameters o=
r<br clear=3D"none">
&gt; vice versa, (seems like same thing) ?<br clear=3D"none">
<br clear=3D"none">
it's similar and to some extent, query strings are a historical aspect <br =
clear=3D"none">
of URI syntax. usually, people use paths when resource structure and <br cl=
ear=3D"none">
navigation is clearly hierarchical (and then being able to "hack" URIs <br =
clear=3D"none">
in the address bar can be very convenient), and query strings are used <br =
clear=3D"none">
when things get more complicated, such as multiple dimensions of how <br cl=
ear=3D"none">
resources are related. that being said, keep in mind that good REST <br cle=
ar=3D"none">
designs should not depend on specific URI patterns anyway, you should <br c=
lear=3D"none">
have a logical view of how you interlink resources. using "pretty URIs" <br=
 clear=3D"none">
then makes your service nicer to use, but your design should work in the <b=
r clear=3D"none">
very same way, regardless of whether you use /Reports/1/pie or <br clear=3D=
"none">
/Reports/1?view=3Dpie<br clear=3D"none">
<br clear=3D"none">
cheers,<br clear=3D"none">
<br clear=3D"none">
d.<br clear=3D"none">
<br clear=3D"none">
-- <br clear=3D"none">
erik wilde | mailto:[email protected]  -  tel:&#43;1-510-2061079 |<br clear=
=3D"none">
            | UC Berkeley  -  School of Information (ISchool) |<br clear=3D=
"none">
            | http://dret.net/netdret http://twitter.com/dret |<br clear=3D=
"none">
</div>


    </div>
=20=20=20=20=20


=20=20=20=20
    <div style=3D"height: 0px;color: rgb(255, 255, 255);"></div></div>




</div></div><br><br></div>  </div> </div>  </div> </div></div></p>

    </div>
=20=20=20=20=20

    <!--~-|**|PrettyHtmlStart|**|-~-->
    <div style=3D"color: #fff; height: 0;">__._,_.___</div>

=20=20=20=20=20=20=20=20=20=20
=20=20
=20

=20=20=20=20
    <div style=3D"clear:both"> </div>

    <table cellspacing=3D4px style=3D"margin-top: 20px; margin-bottom: 10px=
; color: #2D50FD;">
      <tbody>
        <tr>
          <td style=3D"font-size: 12px; font-family: arial; font-weight: bo=
ld; padding: 7px 5px 5px;"  >
                          <a style=3D"text-decoration: none; color: #2D50FD=
" href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/conversations/me=
ssages/19638;_ylc=3DX3oDMTJxbXRzNjF0BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3J=
wc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjM4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTM5OT=
U1Nzg0Mw--?act=3Dreply&messageNum=3D19638">Reply via web post</a>
                      </td>
          <td>&bull;</td>
          <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;" >
            <a href=3D"mailto:[email protected]?subject=3DRe%3A%20%5Brest=
-discuss%5D%20Resources%20and%20presentation%20views" style=3D"text-decorat=
ion: none; color: #2D50FD;">
               Reply to sender            </a>
          </td>
          <td>&bull;</td>
          <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;">
            <a href=3D"mailto:[email protected]?subject=3DRe%3A%=
20%5Brest-discuss%5D%20Resources%20and%20presentation%20views" style=3D"tex=
t-decoration: none; color: #2D50FD">
              Reply to group            </a>
          </td>
          <td>&bull;</td>
          <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;" >
            <a href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/con=
versations/newtopic;_ylc=3DX3oDMTJlNjgwNmo1BF9TAzk3MzU5NzE0BGdycElkAzQzMTky=
NTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTM5OTU1Nzg0Mw-=
-" style=3D"text-decoration: none; color: #2D50FD">Start a New Topic</a>
          </td>
          <td>&bull;</td>
          <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;color: #2D50FD;" >
                            <a href=3D"https://groups.yahoo.com/neo/groups/=
rest-discuss/conversations/topics/19636;_ylc=3DX3oDMTM2bmNzYnFlBF9TAzk3MzU5=
NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjM4BHNlYwNmdHI=
Ec2xrA3Z0cGMEc3RpbWUDMTM5OTU1Nzg0MwR0cGNJZAMxOTYzNg--" style=3D"text-decora=
tion: none; color: #2D50FD;">Messages in this topic</a>
                (3)
                      </td>
        </tr>
      </tbody>
    </table>

=20=20=20=20=20=20=20=20
<div id=3D"megaphoneModule">
=20=20=20=20=20
    <hr style=3D"height:2px ; border-width:0; color:#E3E3E3; background-col=
or:#E3E3E3;">
</div>

<!------- Start Nav Bar ------>




=20

<!-- |**|begin egp html banner|**| -->
<div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-family: Ver=
dana; font-size: 10px; margin-bottom: 10px; padding: 10px;">

    <span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-transf=
orm: uppercase; "><a href=3D"https://groups.yahoo.com/neo/groups/rest-discu=
ss/info;_ylc=3DX3oDMTJlYXNiNjFwBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJ=
ZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTM5OTU1Nzg0Mw--" style=3D"=
text-decoration: none;">Visit Your Group</a></span>

     <ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in=
line;">
            <li style=3D"border-right: 1px solid #000; font-weight: 700; di=
splay: inline; padding: 0 5px; margin-left: 0;">
      <span class=3D"cat"><a href=3D"https://groups.yahoo.com/neo/groups/re=
st-discuss/members/all;_ylc=3DX3oDMTJmZWkzNjJlBF9TAzk3MzU5NzE0BGdycElkAzQzM=
TkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEzOTk1NTc4=
NDM-" style=3D"text-decoration: none;">New Members</a></span>
      <span class=3D"ct" style=3D"color: #ff7900;">2</span>
    </li>
                                              </ul>
  </div>


<div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p=
x; padding: 0 2px 0 0; clear: both;">
  <a href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTJkbTlvamg0BF9TAzk3ND=
c2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxMzk5NTU3ODQz" style=3D"float: left;"><img src=3D"http://l.yimg.com/r=
u/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height=3D"15"=
 width=3D"137" alt=3D"Yahoo! Groups" style=3D"border: 0;"/></a>
  <div style=3D"color: #747575; float: right;"> &bull; <a href=3D"https://i=
nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio=
n: none;">Privacy</a> &bull; <a href=3D"mailto:rest-discuss-unsubscribe@yah=
oogroups.com?subject=3DUnsubscribe" style=3D"text-decoration: none;">Unsubs=
cribe</a> &bull; <a href=3D"https://info.yahoo.com/legal/us/yahoo/utos/term=
s/" style=3D"text-decoration: none;">Terms of Use</a> </div>
</div>
<br>

<!-- |**|end egp html banner|**| -->

  </div> <!-- ygrp-msg -->

=20
  <!-- Sponsor -->
  <!-- |**|begin egp html banner|**| -->
  <div id=3D"ygrp-sponsor" style=3D"width:160px; float:right; clear:none; m=
argin:0 0 25px 0; background: #fff;">

<!-- Start Recommendations -->
<div id=3D"ygrp-reco">
     </div>
<!-- End Recommendations -->



  </div>   <!-- |**|end egp html banner|**| -->

  <div style=3D"clear:both; color: #FFF; font-size:1px;">.</div>
</div>

  <img src=3D"http://geo.yahoo.com/serv?s=3D97359714/grpId=3D4319255/grpspI=
d=3D1705701014/msgId=3D19638/stime=3D1399557843" width=3D"1" height=3D"1"> =
<br>

<img src=3D"http://y.analytics.yahoo.com/fpc.pl?ywarid=3D515FB27823A7407E&a=
=3D10001310322279&js=3Dno&resp=3Dimg" width=3D"1" height=3D"1">=20

<div style=3D"color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->

</body>

<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
  <style type=3D"text/css">
  <!--
  #ygrp-mkp {
  border: 1px solid #d8d8d8;
  font-family: Arial;
  margin: 10px 0;
  padding: 0 10px;
}

#ygrp-mkp hr {
  border: 1px solid #d8d8d8;
}

#ygrp-mkp #hd {
  color: #628c2a;
  font-size: 85%;
  font-weight: 700;
  line-height: 122%;
  margin: 10px 0;
}

#ygrp-mkp #ads {
  margin-bottom: 10px;
}

#ygrp-mkp .ad {
  padding: 0 0;
}

#ygrp-mkp .ad p {
  margin: 0;
}

#ygrp-mkp .ad a {
  color: #0000ff;
  text-decoration: none;
}
  #ygrp-sponsor #ygrp-lc {
  font-family: Arial;
}

#ygrp-sponsor #ygrp-lc #hd {
  margin: 10px 0px;
  font-weight: 700;
  font-size: 78%;
  line-height: 122%;
}

#ygrp-sponsor #ygrp-lc .ad {
  margin-bottom: 10px;
  padding: 0 0;
}

  #actions {
    font-family: Verdana;
    font-size: 11px;
    padding: 10px 0;
  }

  #activity {
    background-color: #e0ecee;
    float: left;
    font-family: Verdana;
    font-size: 10px;
    padding: 10px;
  }

  #activity span {
    font-weight: 700;
  }

  #activity span:first-child {
    text-transform: uppercase;
  }

  #activity span a {
    color: #5085b6;
    text-decoration: none;
  }

  #activity span span {
    color: #ff7900;
  }

  #activity span .underline {
    text-decoration: underline;
  }

  .attach {
    clear: both;
    display: table;
    font-family: Arial;
    font-size: 12px;
    padding: 10px 0;
    width: 400px;
  }

  .attach div a {
    text-decoration: none;
  }

  .attach img {
    border: none;
    padding-right: 5px;
  }

  .attach label {
    display: block;
    margin-bottom: 5px;
  }

  .attach label a {
    text-decoration: none;
  }
=20=20
  blockquote {
    margin: 0 0 0 4px;
  }

  .bold {
    font-family: Arial;
    font-size: 13px;
    font-weight: 700;
  }

  .bold a {
    text-decoration: none;
  }

  dd.last p a {
    font-family: Verdana;
    font-weight: 700;
  }

  dd.last p span {
    margin-right: 10px;
    font-family: Verdana;
    font-weight: 700;
  }

  dd.last p span.yshortcuts {
    margin-right: 0;
  }

  div.attach-table div div a {
    text-decoration: none;
  }

  div.attach-table {
    width: 400px;
  }

  div.file-title a, div.file-title a:active, div.file-title a:hover, div.fi=
le-title a:visited {
    text-decoration: none;
  }

  div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div=
.photo-title a:visited {
    text-decoration: none;
  }

  div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
    font-family: Verdana;
    font-size: 10px;
    font-weight: normal;
  }

  .green {
    color: #628c2a;
  }

  .MsoNormal {
    margin: 0 0 0 0;
  }

  o {
    font-size: 0;
  }

  #photos div {
    float: left;
    width: 72px;
  }

  #photos div div {
    border: 1px solid #666666;
    height: 62px;
    overflow: hidden;
    width: 62px;
  }

  #photos div label {
    color: #666666;
    font-size: 10px;
    overflow: hidden;
    text-align: center;
    white-space: nowrap;
    width: 64px;
  }

  #reco-category {
    font-size: 77%;
  }

  #reco-desc {
    font-size: 77%;
  }

  .replbq {
    margin: 4px;
  }

  #ygrp-actbar div a:first-child {
   /* border-right: 0px solid #000;*/
    margin-right: 2px;
    padding-right: 5px;
  }

  #ygrp-mlmsg {
    font-size: 13px;
    font-family: Arial, helvetica,clean, sans-serif;
    *font-size: small;
    *font: x-small;
  }

  #ygrp-mlmsg table {
    font-size: inherit;
    font: 100%;
  }

  #ygrp-mlmsg select, input, textarea {
    font: 99% Arial, Helvetica, clean, sans-serif;
  }

  #ygrp-mlmsg pre, code {
    font:115% monospace;
    *font-size:100%;
  }

  #ygrp-mlmsg * {
    line-height: 1.22em;
  }

  #ygrp-mlmsg #logo {
    padding-bottom: 10px;
  }


  #ygrp-msg p a {
    font-family: Verdana;
  }

  #ygrp-msg p#attach-count span {
    color: #1E66AE;
    font-weight: 700;
  }

  #ygrp-reco #reco-head {
    color: #ff7900;
    font-weight: 700;
  }

  #ygrp-reco {
    margin-bottom: 20px;
    padding: 0px;
  }

  #ygrp-sponsor #ov li a {
    font-size: 130%;
    text-decoration: none;
  }

  #ygrp-sponsor #ov li {
    font-size: 77%;
    list-style-type: square;
    padding: 6px 0;
  }=20

  #ygrp-sponsor #ov ul {
    margin: 0;
    padding: 0 0 0 8px;
  }

  #ygrp-text {
    font-family: Georgia;
  }

  #ygrp-text p {
    margin: 0 0 1em 0;
  }

  #ygrp-text tt {
    font-size: 120%;
  }

  #ygrp-vital ul li:last-child {
    border-right: none !important;=20
  }=20
  -->
  </style>
</head>

<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->


---1593584224-1419688989-1399532458=:57409--