[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRD and JSON
--Apple-Mail-67--537614811 Content-Type: multipart/alternative; boundary=Apple-Mail-66--537615908 --Apple-Mail-66--537615908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you explain the initial use case a bit for us? John B. On 2010-04-22, at 5:45 PM, Will Norris wrote: > you either have: > 1) a no-brainer method of switching between XML and JSON like = JsonML, and then have to do some work to get the JSON into the right = logical object, or > 2) a no-brainer JSON format that can be used as-is, and you have to = do a little work to switch between the XML and JSON formats >=20 > It's just a matter of which one you want to optimize for. >=20 > Signatures are of course an issue, and I don't really have an answer = for that. The immediate use-case we're looking at wouldn't necessarily = need signatures, though. >=20 > -will >=20 >=20 > On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <jbradley@mac.com> = wrote: > I am still trying to understand the use case. >=20 > Having multiple discovery formats each requiring separate processing = is not optimal. >=20 > Being able to transform from one to the other may have advantages. >=20 > I am speculating that the Google wants a discovery format that can be = entirely parsed with JS inside the browser. >=20 > I am not personally religious about XML.=20 >=20 > If a JSON format that can be transformed into the equivalent XML XRD = can be specified that may be a useful work product for the TC. >=20 > My main concerns are around signatures if this starts being used on = the server as well as in the browser. >=20 > The Google seems to have decided this week that going outside the = existing standards development process is more efficient. > I would prefer that this not result in competing discovery standards. >=20 > It is worth discussing, but at the end of the day Google may need to = do what it needs to do. >=20 > John B. >=20 > On 2010-04-22, at 3:04 PM, Will Norris wrote: >=20 >> On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <cantor.2@osu.edu> = wrote: >> > JsonML does a far better job than some other similar utilities I've = seen, >> so >> > that is certainly nice. And for it's stated goals of providing a = compact >> > format for transporting XML, it works great. But that kind of = misses the >> > point of using JSON, which is to provide an natural representation = of the >> > object, not just a document. >>=20 >> I think the document is the natural representation. A simple layer of = code >> addresses whatever limitations might exist in the language that's = purporting >> to be too difficult to use the document in. >>=20 >> But as a matter of specification, the problem you have is that, like = SAML, >> there's an explicit characterization of the notion of an XRD as being = XML. >> If it's not XML, it's not an XRD. I have not seen a simple way around = that. >>=20 >> A separate specification can be created to establish an interchange = format >> in some other encoding with a different label attached to it, but if = the >> goal here was to allow for non-XML representations of an XRD, it = would >> require some fairly big changes that I'm pretty comfortable saying = nobody >> wants to take on. >>=20 >> certainly, I wasn't meaning to suggest a departure of any kind from = how XRD is defined today. I've been quite upfront from the beginning of = my involvement with this TC that I view XRD (as it's specified) solely = as an XML format, and if you want something else, then do it yourself. = Well, now Google is sort of doing it ourselves, and we figured that if = others end up wanting to do the same, it might be good to have agreement = on what that JSON format looks like. That could just be a whitepaper, a = best practice guide, or whatever. It certainly doesn't have to be a = product of this TC, I just thought I would see if it was anything folks = had any interest in it. >>=20 >> -will >=20 >=20 --Apple-Mail-66--537615908 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Can you explain the initial use case a bit for us?<div><br></div><div>John B.<br><div><div>On 2010-04-22, at 5:45 PM, Will Norris wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">you either have:<div> 1) a no-brainer method of switching between XML and JSON like JsonML, and then have to do some work to get the JSON into the right logical object, or</div><div> 2) a no-brainer JSON format that can be used as-is, and you have to do a little work to switch between the XML and JSON formats</div> <div><br></div><div>It's just a matter of which one you want to optimize for.</div><div><br></div><div>Signatures are of course an issue, and I don't really have an answer for that. The immediate use-case we're looking at wouldn't necessarily need signatures, though.</div> <div><br></div><div>-will</div><div><br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <span dir="ltr"><<a href="mailto:jbradley@mac.com";>jbradley@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div style="word-wrap:break-word">I am still trying to understand the use case.<div><br></div><div>Having multiple discovery formats each requiring separate processing is not optimal.</div><div><br></div><div>Being able to transform from one to the other may have advantages.</div> <div><br></div><div>I am speculating that the Google wants a discovery format that can be entirely parsed with JS inside the browser.</div><div><br></div><div>I am not personally religious about XML. </div><div><br></div> <div>If a JSON format that can be transformed into the equivalent XML XRD can be specified that may be a useful work product for the TC.</div><div><br></div><div>My main concerns are around signatures if this starts being used on the server as well as in the browser.</div> <div><br></div><div>The Google seems to have decided this week that going outside the existing standards development process is more efficient.</div><div>I would prefer that this not result in competing discovery standards.</div> <div><br></div><div>It is worth discussing, but at the end of the day Google may need to do what it needs to do.</div><div><br></div><div>John B.</div><div><div></div><div class="h5"><div><br><div><div>On 2010-04-22, at 3:04 PM, Will Norris wrote:</div> <br><blockquote type="cite"><div class="gmail_quote">On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <span dir="ltr"><<a href="mailto:cantor.2@osu.edu"; target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>> JsonML does a far better job than some other similar utilities I've seen,<br> so<br> > that is certainly nice. And for it's stated goals of providing a compact<br> > format for transporting XML, it works great. But that kind of misses the<br> > point of using JSON, which is to provide an natural representation of the<br> > object, not just a document.<br> <br> </div>I think the document is the natural representation. A simple layer of code<br> addresses whatever limitations might exist in the language that's purporting<br> to be too difficult to use the document in.<br> <br> But as a matter of specification, the problem you have is that, like SAML,<br> there's an explicit characterization of the notion of an XRD as being XML.<br> If it's not XML, it's not an XRD. I have not seen a simple way around that.<br> <br> A separate specification can be created to establish an interchange format<br> in some other encoding with a different label attached to it, but if the<br> goal here was to allow for non-XML representations of an XRD, it would<br> require some fairly big changes that I'm pretty comfortable saying nobody<br> wants to take on.</blockquote><div><br></div><div>certainly, I wasn't meaning to suggest a departure of any kind from how XRD is defined today. I've been quite upfront from the beginning of my involvement with this TC that I view XRD (as it's specified) solely as an XML format, and if you want something else, then do it yourself. Well, now Google is sort of doing it ourselves, and we figured that if others end up wanting to do the same, it might be good to have agreement on what that JSON format looks like. That could just be a whitepaper, a best practice guide, or whatever. It certainly doesn't have to be a product of this TC, I just thought I would see if it was anything folks had any interest in it.</div> <div><br></div><div>-will</div></div> </blockquote></div><br></div></div></div></div></blockquote></div><br></div> </blockquote></div><br></div></body></html> --Apple-Mail-66--537615908-- --Apple-Mail-67--537614811 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA0 MjIyMjIwNDVaMCMGCSqGSIb3DQEJBDEWBBQ7WwZ2jYCDmJn3jkADE5KBZB62ljCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAVrf34AyVa55heBxC4oFRiDHLBHMPbo7vkD6XEUAqXsjlZz9FJX0YykcxUXdnG9R/g+r3/T2vt Vmp+pQ1uaSinlhUP/8Me73qsw4wbKsxEb5pt5qtLgWQF79np0JWpYdVDeJcXsLDeCyFX+N+TCFGG S5+eBdoj5XJ/SsgWSfB0a2qx+gHqk+NPp6DQUEo2adJcGkrjfJhZECztjiYnsJxqwSFT6bRqn5OQ Tfssvh4hY0xi1Hm8vk84d5qECrGdATt2PRKUUrNSeuSapDsfYYmMvpHqYwlBrQfWNz1zEVAGb6M2 HrmgqQvtAmU7kQue+l7/PNHZP0Pgu2fCBvhcPBJ1AAAAAAAA --Apple-Mail-67--537614811--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]