Please hammer the ID schema!

[Anthony Bryan]

I just found an error in the ID schema, where the priority attribute
of url/metaurl was required.

I can only read this thing so many times before my eyes glaze :)

so I encourage everyone to try the schema out, introduce errors in
otherwise fine metalinks & see if the schema catches em.

the latest schema can be found in the updated ID at
http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/

but I'll attach it here along with a test metalink

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

[Tatsuhiro Tsujikawa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Anthony Bryan wrote:
> I just found an error in the ID schema, where the priority attribute
> of url/metaurl was required.
>

I fixed the same thing in 4.2.8 and 4.2.16.

I just thought how clients should treat URL if priority is missing.
If a Metalink contains URL with priority and URL without it, should
client assume that URL without it have lowest priority or opposite?

I also found metalink:logo and metalink:origin has metalinkUri construct
with parenthesis.

metalinkOrigin =
element metalink:origin {
metalinkCommonAttributes,
attribute dynamic { xsd:boolean }?,
(metalinkUri)
}

Other elements have not parenthesis.

metalinkMetaURL =
element metalink:metaurl {
metalinkCommonAttributes,
attribute priority { xsd:positiveInteger {
maxInclusive = "999999"}}?,
attribute type { text },
attribute name { text }?,
metalinkUri
}

I think this is not significant for validation. But should we remove
parenthesis?

Best regards,

Tatsuhiro Tsujikawa

> I can only read this thing so many times before my eyes glaze :)
>
> so I encourage everyone to try the schema out, introduce errors in
> otherwise fine metalinks & see if the schema catches em.
>
> the latest schema can be found in the updated ID at
> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/
>
> but I'll attach it here along with a test metalink
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksxuK4ACgkQfoQD1dZzw2Z3wACfcSMy/BY/d7RWEhqvN/2Gch9m
+4cAnjlZyWdzRDTHTFe7JoiOKb68nXbX
=erMM
-----END PGP SIGNATURE-----

[Anthony Bryan]

On Wed, Dec 23, 2009 at 1:29 AM, Tatsuhiro Tsujikawa
<tatsu...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Anthony Bryan wrote:
>> I just found an error in the ID schema, where the priority attribute
>> of url/metaurl was required.
>>
>
> I fixed the same thing in 4.2.8 and 4.2.16.

argh, thought I did that. thanks!

> I just thought how clients should treat URL if priority is missing.
> If a Metalink contains URL with priority and URL without it, should
> client assume that URL without it have lowest priority or opposite?

I'd guess lowest if it wasn't important enough to put in there. what
do you think? we can save that for the client spec.

> I also found metalink:logo and metalink:origin has metalinkUri construct
> with parenthesis.
>
>   metalinkOrigin =
>      element metalink:origin {
>        metalinkCommonAttributes,
>        attribute dynamic { xsd:boolean }?,
>        (metalinkUri)
>      }
>
> Other elements have not parenthesis.
>
>   metalinkMetaURL =
>      element metalink:metaurl {
>         metalinkCommonAttributes,
>         attribute priority { xsd:positiveInteger {
>            maxInclusive = "999999"}}?,
>         attribute type { text },
>         attribute name { text }?,
>         metalinkUri
>      }
>
> I think this is not significant for validation. But should we remove
> parenthesis?

I noticed that too. I'm not sure, but looking at Atom schema
http://tools.ietf.org/html/rfc4287#appendix-B
it looks like it is always in paretheses.

atomIcon = element atom:icon {
atomCommonAttributes,
(atomUri)
}

atomId = element atom:id {
atomCommonAttributes,
(atomUri)

[Tatsuhiro Tsujikawa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Bryan wrote:
>> I just thought how clients should treat URL if priority is missing.
>> If a Metalink contains URL with priority and URL without it, should
>> client assume that URL without it have lowest priority or opposite?
>
> I'd guess lowest if it wasn't important enough to put in there. what
> do you think? we can save that for the client spec.
>

I think we should state that client should treat resources at lowest
priority if priority attribute is missing, because we need consensus
between generator and clients that client will use resources in the
order as generators expect.

I propose to add following at the end of 4.2.8.1 and 4.2.16.1:

If priority attribute is missing, clients should treat those elements
as lowest priority.

OK, I think we can leave them untouched, because it causes no harm.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkszbYIACgkQfoQD1dZzw2Y7vgCg2bqceo+iXSduYjxly9lFyWvT
ZrkAoNArNBI2cSzF3kOsWAqT8BTy8QQU
=lrSb
-----END PGP SIGNATURE-----

[Anthony Bryan]

On Thu, Dec 24, 2009 at 8:32 AM, Tatsuhiro Tsujikawa
<tatsu...@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Anthony Bryan wrote:
>>> I just thought how clients should treat URL if priority is missing.
>>> If a Metalink contains URL with priority and URL without it, should
>>> client assume that URL without it have lowest priority or opposite?
>>
>> I'd guess lowest if it wasn't important enough to put in there. what
>> do you think? we can save that for the client spec.
>>
>
> I think we should state that client should treat resources at lowest
> priority if priority attribute is missing, because we need consensus
> between generator and clients that client will use resources in the
> order as generators expect.
>
> I propose to add following at the end of 4.2.8.1 and 4.2.16.1:
>
> If priority attribute is missing, clients should treat those elements
> as lowest priority.

how about?

elements without a priority attribute are considered to have the
lowest priority, i.e. 999999.

is the whole text confusing? I've added a few small clarifications.

4.2.8.1. The "priority" Attribute

metalink:metaurl (The "metalink:metaurl" Element) elements MAY have a
priority attribute. Values MUST be positive integers between 1 and
999999. Lower values indicate a higher priority. metalink:metaurl (The
"metalink:metaurl" Element) elements without a priority attribute are
considered to have the lowest priority, i.e. 999999. The priority
values of metalink:metaurl (The "metalink:metaurl" Element) and
metalink:url (The "metalink:url" Element) elements are compared and
those with the lowest values, starting with 1, are used first.
Multiple metalink:metaurl (The "metalink:metaurl" Element) and
metalink:url (The "metalink:url" Element) elements MAY have the same
priority, i.e. one BitTorrent .torrent file and three FTP URIs could
have priority="1". See also the "priority" attribute of the
metalink:url (The "metalink:url" Element) element.

I changed them to be more consistent with what we are borrowing from Atom.

[Tatsuhiro]

Looks good for me.

Great, it looks much better. Thanks.