so, you proposed a range of 1 to 255...

 any objections or other suggestions? :)

On Sun, Nov 29, 2009 at 8:23 AM, Matthias Fuchs <[email protected]> wrote:
> 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"
>



-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

--

You received this message because you are subscribed to the Google Groups 
"Metalink Discussion" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/metalink-discussion?hl=en.


Reply via email to