Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Martin,

Am 14.12.2009 um 00:48 schrieb Thomson, Martin:

I'm not sure I understand the whitespace treatment.

One example has:

  <url location="de" priority="1">
     ftp://ftp.example.com/example.ext
  </url>	
...

"All leading and trailing whitespace is part of the element content,
and MUST be ignored. Consequently, it is disallowed for elements
where
the defined type does not allow whitespace, such as dates, integers,
or IRIs."

Um, that should be "MUST NOT be ignored", right?

Fixed.

Why is whitespace so important? The alternative to constraining use as you have done, which requires that you also "fix" all the examples, is to use the type that fits better with user expectations: token.

In the *value space* for the token type, the above example is simply "ftp://ftp.example.com/example.ext";, with leading and trailing whitespace stripped.

Then you can remove the following note:
Note that there MUST NOT be any white space in a Date construct or in
  any IRI.  Some XML-generating implementations erroneously insert
  white space around values by default, and such implementations will
  generate invalid Metalink Documents.

... and with it, avoid all the errors that inevitably occur when you make whitespace significant. Unless you believe that Metalink documents will never be authored by anything other than software.

In looking into this, I noted this:
  # Unconstrained; it's not entirely clear how IRI fit into
  # xsd:anyURI so let's not try to constrain it here

I wonder why you haven't taken the plunge on xsd:anyURI, even if xsd:anyURI has dubious official status with regards to IRIs. In practice, IRIs are commonly placed in xsd:anyURI. The lexical space accommodates them, no implementation I'm aware of prevents use of IRIs.

Thanks for the interesting suggestion. Thought about it for a while, asked some people, but now I think that what matters most is that it's clearly specified, as Julian pointed out. I now think it's fine as it is.

We still have to fix the examples. I'll do it now in svn.

Peter

<<attachment: smime.p7s>>

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]