- From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Aug 2018 22:31:06 +0000
- To: public-dxwg-wg@w3.org
There seem to be four distinct issues with dcat:byteSize as the only option: 1) very large numbers - certainly not human readable practically 2) exact semantics - is this expected to be exact or approximate? what if the resource varies over time and the exact value cannot be predicted 3) cost of computation of exact bytesize 4) difference in values with different encoding choices that may be negotiated for a distribution what feels to me "reasonable" is to keep byteSize with tighter definition about its expected semantics and introduce a new term with a simple string literal with a microformat eg dcat:approxSize "23 MB" such microformats are extremely common, but I havent had too much luck tracking down a standard for such a format, but there are ones for the actual postfix part - and a confusion over K = 1000 or 1024 and some ISO rules - and there are explict (e.g. KB and KiB) postfixes for these cases. IMHO this would not matter if approximation is the semantics - though would still need to be careful about byte-vs-bit (KB vs Kb)- which is an effective order of magnitude. Here are two major development platforms that explicitly support such formats, without citing standards conformance, but do reference this issue of interpretation. https://developer.android.com/reference/android/text/format/Formatter#formatFileSize(android.content.Context,%20long) https://docs.microsoft.com/en-us/windows/desktop/api/shlwapi/nf-shlwapi-strformatbytesizeex -- GitHub Notification of comment by rob-metalinkage Please view or discuss this issue at https://github.com/w3c/dxwg/issues/313#issuecomment-417488373 using your GitHub account
Received on Thursday, 30 August 2018 22:31:37 UTC