OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD and JSON


--Apple-Mail-62--544508643
Content-Type: multipart/alternative;
	boundary=Apple-Mail-61--544509680


--Apple-Mail-61--544509680
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I am still trying to understand the use case.

Having multiple discovery formats each requiring separate processing is =
not optimal.

Being able to transform from one to the other may have advantages.

I am speculating that the Google wants a discovery format that can be =
entirely parsed with JS inside the browser.

I am not personally religious about XML.=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.

My main concerns are around signatures if this starts being used on the =
server as well as in the browser.

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.

It is worth discussing, but at the end of the day Google may need to do =
what it needs to do.

John B.

On 2010-04-22, at 3:04 PM, Will Norris wrote:

> 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


--Apple-Mail-61--544509680
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.&nbsp;</div><div><br></div><div>If a JSON =
&nbsp;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><br><div><div>On =
2010-04-22, at 3:04 PM, Will Norris wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
class=3D"gmail_quote">On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor =
<span dir=3D"ltr">&lt;<a =
href=3D"mailto:cantor.2@osu.edu";>cantor.2@osu.edu</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">&gt; JsonML does a far better job than some other =
similar utilities I've seen,<br>
so<br>
&gt; that is certainly nice. &nbsp;And for it's stated goals of =
providing a compact<br>
&gt; format for transporting XML, it works great. &nbsp;But that kind of =
misses the<br>
&gt; point of using JSON, which is to provide an natural representation =
of the<br>
&gt; 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. &nbsp;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. =
&nbsp;Well, now Google is sort of doing it ourselves, and we =
figured&nbsp;that if others end up wanting to do the same, it might be =
good to have agreement on what that JSON format looks like. &nbsp;That =
could just be a whitepaper, a best practice guide, or whatever. &nbsp;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></body></html>=

--Apple-Mail-61--544509680--

--Apple-Mail-62--544508643
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
MjIyMDI1NTFaMCMGCSqGSIb3DQEJBDEWBBRACofj8gr/WsnJGSDpAAiqHYSZNjCBpAYJKwYBBAGC
NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g
Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC
AQApRaPAjqAkbr+f8XdRiUvlTrQf/65LXmfojBFYFqW2xJSuOKe+c2CxS6wbD7Gx/04RU5qf5oGk
YApsEugfu21P1wYt2BwWqB+uR6nE7yaI2c/vW7fTDxLEKwgjSvvvZ4UVkub2OllRIkx5XH4hoitl
qGh+XOPiUnPwwzordbYr6BVb8ChZneHADqGKoQi3g0Yi3p9tpl2xhUmgf7WSjlqggeKmUZTK82kj
2uT/9lrdxHon2QggEkpIbh6iZUQmVwyCrS6+wTZazELtlrYdxl8Uis62GVlMnkzhjUIWUPD1jTek
EXd2rMHpm6dGp4KdNIsOCiRSuqLBVhbKSWTthWnJAAAAAAAA

--Apple-Mail-62--544508643--


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]