Am Dienstag 24 November 2009 17:10:25 schrieb Anthony Bryan: > On Tue, Nov 24, 2009 at 10:38 AM, Tatsuhiro <[email protected]> wrote: > > On 11月22日, 午前3:45, Anthony Bryan <[email protected]> wrote: > >> On Sun, Nov 15, 2009 at 6:31 AM, Matthias Fuchs <[email protected]> wrote: > >> > So far the Pieces length, MetaURL priority and URL priority use > >> > xsd:integer. > >> > > >> > Yet none of these defines an applicable range. What that means is that > >> > negative values would be valid as well according to the draft even if > >> > they made no sense at all. In fact for the Pieces length this is > >> > probably not the case as the description in the draft should be enough > >> > to provide a positive range. > >> > > >> > So in my opinion we should either add a range or change them to one of > >> > the unsigned PODS. In that case we still have to define that 0 is not > >> > to be used for pirority. > >> > > >> > In terms of priority I would opt for a range as imo a priority of > >> > 268435456 would rather be confusing if it was also shown to the user > >> > not just used internally. We could use xsd:unsignedByte for example, > >> > when we would have only positive values and automatically a range (if > >> > we exclude 0 in fact) from 1 to 255. > >> > > >> > What do you think on that? > >> > >> good catch, Matthias! > >> > >> pieces length, I think defining a range might be hard. I think the > >> default torrent chunk size is 256k. max range, who knows? limiting it > >> to positive integers should be good, right? > >> > >> priority for metaurl and url, a range wouldn't be bad. does anyone > >> else want 1 to 255? > > > > I also think it is not bad, but I saw float priority(like 23.444) > > somewhere(maybe mandriva?) in some time ago. > > ah yes...well, this is the new version, I don't think outlawing that > for the future version is a prob, unless you think we need float? > > >> On Sun, Nov 15, 2009 at 4:45 PM, Nicolas Alvarez > >> > >> <[email protected]> wrote: > >> > Matthias Fuchs wrote: > >> >> So in my opinion we should either add a range or change them to one > >> >> of the unsigned PODS. In that case we still have to define that 0 is > >> >> not to be used for pirority. > >> > > >> > IIRC, XSD has different types for "positive" and "nonnegative". The > >> > former doesn't include 0. > >> > >> positiveInteger, nonNegativeInteger? > >> > >> do I just need to replace "integer" in the schema with > >> "positiveInteger"? > > > > For file size, technically, it is nonNegativeInteger. I think it is > > safe to include 0. > > I know downloading 0 byte file is non-sense of course.. > > another good catch in this thread, file size is not restricted to > integer even, it was metalinkTextConstruct. > > metalinkSize = > element metalink:size { > xsd:nonNegativeInteger > > ? > > piece, & both priority changed to positiveInteger I know that I'm nitpicking [1] here but according to [2] this includes any postive integer from a _mathematical_ viewpoint:
"The value space of xsd:positiveInteger includes the set of the strictly positive integers (excluding zero), with no restriction of range." As such there is no integer-type (here in informatics) that could support the possible range. Thus I'm still for setting a fixed maximum, so that implentors of Metalink can be sure that any valid number will work with their used data- type and not result in an integer overflow. [1] As this should not be a problem with sane users [2] http://books.xmlschemata.org/relaxng/ch19-77279.html see "Description" and "Example"
signature.asc
Description: This is a digitally signed message part.
