<br><br><div class="gmail_quote">On Wed, Jun 17, 2009 at 7:01 AM, Shawn Villaron <span dir="ltr"><<a href="mailto:shawnv@microsoft.com">shawnv@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p>What's the migration story for files which pre-date 29500? For example, suppose I have a binary wordprocessing document and it contains the equivalent @uri value of something like "c:\users\shawnv\desktop"? </p>
</div></div></blockquote><div>then the migration is "file://c:/users/shwanv/desktop"<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p>Are you suggesting that there is no upgrade path to Strict for such files? </p></div></div></blockquote><div><br>no see above<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US"><div><p>Wouldn't this bring is into direct conflict with the existing scope of 29500?</p><p> </p><p>I wonder if there is the opportunity to slightly shift your proposal:</p>
<p> </p><p style="margin-left: 0.5in; text-indent: -0.25in;"><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span></span>In "transitional", we offer no guidance</p>
<p style="margin-left: 0.5in; text-indent: -0.25in;"><span style="font-family: Symbol;"><span>·<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span></span>In "strict", we offer guidance that <i>should</i> use a namespace name</p>
<p> </p><p>The data type is going to be similarly tricky, for the same reasons.</p><div><div></div><div class="h5"><p> </p><p> </p><p>-----Original Message-----<br>From: MURATA Makoto (FAMILY Given) [mailto:<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>] <br>
Sent: Saturday, June 13, 2009 6:11 AM<br>To: SC 34 WG4<br>Subject: Re: DR 09-0210: WML: Custom XML and Smart Tags</p><p> </p><p>> I would like to explicitly state @uri shall specify a namespace name </p><p>> and @element shall specify a local name. (BTW, "element type" as </p>
<p>> defined in XML 1.0 is a string containing prefixses (optional), ":" </p><p>> (optional), and local names. "Local name" is the best terminology.)</p><p> </p><p> </p><p>Smart tags and custom XML markup should represent embedded foreign XML elements. However, during the last teleconf, Shawn reported that foreign "elements" embedded in existing binary documents contain illegal namespace names. Thus, if we would like to capture existing binary documents, we cannot disallow illegal namespace names for the uri attribute. This observation does not apply to local names of embedded foreign elements.</p>
<p> </p><p>Having heard this observation, I would change my proposal. </p><p> </p><p>In "strict", we should require that @uri specify a namespace name. </p><p>The schema in Part 1 should specify xsd:anyURI.</p>
<p> </p><p>In "transitional", we should recommend that @uri specify a namespace name. </p><p>The schema in Part 1 should specify xsd:string.</p><p> </p><p>In both classes, we should require that @element shall specify a local name. The schema in Part 1 should specify xsd:NCName.</p>
<p> </p><p>Cheers,</p><p>Makoto</p><p> </p></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Innovimax SARL<br>Consulting, Training & XML Development<br>9, impasse des Orteaux<br>75020 Paris<br>
Tel : +33 9 52 475787<br>Fax : +33 1 4356 1746<br><a href="http://www.innovimax.fr">http://www.innovimax.fr</a><br>RCS Paris 488.018.631<br>SARL au capital de 10.000 €<br>