--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 <> =
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 <> =
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:"></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:" target="_blank"></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--
