So remember, our current "id" is going thru maybe about a dozen different layers on any given access and not getting mangled (L1, L2, L3, L4, TCP, HTTP, GZIP, NFS, EXT3, JVM, UTF16, XML, JSON, etc, etc). Yes, the XML parser did not properly support XML entities, so I made a ticket to fix this:
https://issues.apache.org/jira/browse/DMAP-84 So lets throw away the "strings are unsafe because they can be mangled" argument because once we address DMAP-84, it goes away. >> but GUIDs have their advantages [testable format for starters] -- that will >>henceforth *never* change 'id' is testable. 'id' never changes, never has, why will it now? I still dont see why we need to use a GUID? 'iPod' vs '21EC2020-3AEA-4069-A2DD-08002B30309D'. I choose 'iPod'. ________________________________ From: eberhard speer jr. <[email protected]> To: "'[email protected]'" <[email protected]> Sent: Monday, August 25, 2014 4:45 PM Subject: Re: Data 2.0 - Vocabulary Properties : ddr_ and guid -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A reply. > You didnt answer any of my questions. Ever so sorry, will address that now. > Id : This attribute also has the added bonus that its human > readable. This attribute also has the added bonus of getting mangled [encoded] depending on the transport, serialization used ! > See how easily that 'id' is for us to manage... Look at vendor "barnes & noble" and vendor "barnes and noble" in the DeviceMap data and see how easily *non*-key data get's mangled... Look at your own JIRA DMAP-84 to see how easily entity stuff and encoding particular to transport, serialization get to your IDs ! We know this ! We have actually seen it in our own data and code ! We can prevent this ! Introducing, NEXT to a human-readable 'pseudo-key' [a common practice], a real 'primary key', an id that travels well : ie : not 'mangled' in transport or serialization and defend against this all too common mistake. > What exactly does a GUID give us? And where would you store this > metadata? So, when the XML resources are published [1] the Devices' human readable etc 'Id' attribute is *supplemented* with a GUID or some other thing -- but GUIDs have their advantages [testable format for starters] -- that will henceforth *never* change and is not affected by transport, serialization etc...which leads, as we all well know and see to data corruption. > How and why would the client use the GUID? And if we use it internally so as not to get confused why not share that benefit with all those much less aware of transport, serialization and other pitfalls when it comes to data. Having a consistent id is *vital*. > Are you proposing switching all the 'id' fields to random GUID > values??? No !!! I'm not interested in where the GUID is generated, I'm not interested whether browsers should have a GUID, I'm not interested that 'GUID' is not attribute, it is if 'Id' is...I'm interested in sane, safe data. That's as clear as I can put it and this is *important* ! esjr [1] I do trust you are not suggesting 'publishing' based on manually editing the XML based on JIRA... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT+6BkAAoJEOxywXcFLKYcG54H/3ixcLNfVY97Cp4oxI6x9JkU YSzfv3pTgHOgmgkMChZ9wA2a1JCPsW1K/ScKvnFBJfYpLOb2+7bWaowGRvz2A79R 0XQmiYFWnCjMbSjx3iFwRMubNzAFTiwT/p7Hvf4L4mc2CHqmjdj2H/7bnrcDsXdj lS92vwZNiPygKa4MyHBBeFh5LuqlLm2p7A5Au9CETGxdk9Qk4vv0oPUez7SHbhtB nvuQ1WPmGRV3usqdFrn/t3kopBylNvlfSwIh0UubIQF19siDyoi2XI7Psf1hV0sa SHSoQvXgrA24w4Dp0efo8yTtedgg4DbrNIC1jGLqe7eJGIICt/yXTkWt0LH+2cI= =cY/e -----END PGP SIGNATURE-----
