Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf