Metalink and xsd:integer
Matthias Fuchs
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?
Cheers,
matthias
Nicolas Alvarez
> 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.
Anthony Bryan
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?
On Sun, Nov 15, 2009 at 4:45 PM, Nicolas Alvarez
<nicolas...@gmail.com> 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.
>
> doesn't include 0.
do I just need to replace "integer" in the schema with "positiveInteger"?
metalinkPieces =
element metalink:pieces {
attribute length { xsd:integer },
attribute type { text },
metalinkHash+
metalinkMetaURL =
element metalink:metaurl {
metalinkCommonAttributes,
attribute priority { xsd:integer }?,
attribute type { text },
attribute name { text }?,
metalinkUri
metalinkURL =
element metalink:url {
metalinkCommonAttributes,
attribute location { xsd:string {
minLength = "2" maxLength="2"}
}?,
attribute priority { xsd:integer }?,
metalinkUri
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
Tatsuhiro
> On Sun, Nov 15, 2009 at 6:31 AM, Matthias Fuchs <ma...@gmx.net> 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?
>
somewhere(maybe mandriva?) in some time ago.
> On Sun, Nov 15, 2009 at 4:45 PM, Nicolas Alvarez
>
>
> > 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"?
>
safe to include 0.
I know downloading 0 byte file is non-sense of course..
Anthony Bryan
for the future version is a prob, unless you think we need float?
>> On Sun, Nov 15, 2009 at 4:45 PM, Nicolas Alvarez
>>
>> <nicolas.alva...@gmail.com> 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..
integer even, it was metalinkTextConstruct.
metalinkSize =
element metalink:size {
xsd:nonNegativeInteger
?
piece, & both priority changed to positiveInteger
Matthias Fuchs
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
any objections or other suggestions? :)
Ant Bryan
On Nov 29, 4:25 pm, Anthony Bryan <anthonybr...@gmail.com> wrote:
> 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 <ma...@gmx.net> wrote:
> > Am Dienstag 24 November 2009 17:10:25 schrieb Anthony Bryan:
Peter Pöml
Am 29.11.2009 um 22:25 schrieb Anthony Bryan:
> so, you proposed a range of 1 to 255...
>
> any objections or other suggestions? :)
Regarding metaurl and url, doesn't this effectively limit the number
of (ordered) metaurls/urls to 255? This would seem like an arbitrary -
and needless- restriction to me. There should be no reason why the
specification should forbid 1000 urls that are all ordered, which
could be a valid use case, for whatever reason. I agree that the spec
should be definite, but it shouldn't put up restrictions that are not
needed I think. If limiting the numbers, I'd suggest a reasonably
large range that matches a commonly used datatype, like a short int
(16-bit) or an int (32-bit), which would leave ample room (one would
think).
However, the spec doesn't give any guidance yet about the use case of
the priorities. The use case we have in mind is that we start with 1
(highest priority) (where we started with 99 in the past and counted
in the opposite direction), and then increment the value, right? That
could be made explicit (although there doesn't need to be a
requirement about fixed increments either). Anyway, the relative
difference of the priorities is what matters. Maybe an alternative to
defining a fixed a range could be to describe a suggested usage;
because if people start counting at 1 and use increments of 1, and not
10 or 100 (which they might happen to do), the chances of hitting
funny limits would be much higher.
Even _if_ specifying a range, it might be useful to suggest the
following: a client that can process datatypes only of a certain size
might ignore those entries that come with a higher (larger number)
priority than whatever their implementation choses to being unable to
process. Does this make sense? Or am I crazy? :-)
Altogether, I think it would be useful if the spec suggests to start
counting at 1, increment in steps of 1, _in_order_to_ decrease the
chances that any potential client might run into a limit. A client
should support at least priorities to 255 (absolute minimum), but
better one byte more ;-)
Well, it's just my opinion.
Difficult matters. One should have more experience in protocol design ;)
Peter
Matthias Fuchs
You can have an unlimited number of urls as they can have the same priority.
So there is no reason why you should always increment with 1. Additionally
there is no definition of how the relative difference is to be treated. That
is all up to the application developers.
What you should also keep in mind is that locations can be defined. In case
you have 10 urls with the same priority you could still rank them more finely
if locations are specified.
Btw. for 3.0 2nd ed it was 100 to 1 so you could have started with 99. ;)
The range 1-255 I suggested was just a number that matches a datatype
(unsigned char).
matthias
Anthony Bryan
apps-d...@ietf.org, where metalink ID stuff should be discussed.
IETF people like that, whereas I almost feel like I'm intruding :)
I don't think 100 was too limiting, but maybe as more people use
metalink 255 would be. I'm thinking of "640K should be enough for
everybody" :)
Peter Pöml
Yes - that's why I wrote "ordered". Maybe it wasn't clear enough,
sorry: I was referring *only* to the number of URLs with differing
priority, not to the number of URLs with identical priority, the
latter is obviously not limited by the range.
> So there is no reason why you should always increment with 1.
I'm not sure how you meant that - if you say, there's no reason to
always increment at all, I have to say that I have to in most cases,
if I want to create an ordered list within a country. (And there are
also quite many countries.) There's a practical use case that I have
in mind, it's not made up or academical - I certainly hope that the
number of openSUSE mirrors grows by a factor of 2 or more in the
coming years, although I don't know if it will happen.
If you rather meant "no reason why you should use increments as small
as 1", then I'd counter that a small range of 1-255 would be a very
good reason to prefer small increments over larger ones... ;-)
Surely I wouldn't want to see a limit of 255 priorities.
It's not that I don't like the idea of the definition as such, and the
binding & clarity that it brings, it's just that I would either make
it bigger or be less limiting.
> Additionally
> there is no definition of how the relative difference is to be
> treated. That
> is all up to the application developers.
>
> What you should also keep in mind is that locations can be defined.
> In case
> you have 10 urls with the same priority you could still rank them
> more finely
> if locations are specified.
>
> Btw. for 3.0 2nd ed it was 100 to 1 so you could have started with
> 99. ;)
>
> The range 1-255 I suggested was just a number that matches a datatype
> (unsigned char).
>
> matthias
Thanks for discussing this interesting point!
Peter