Re: Validation error from base 64 encoded data in an object element.

Honestly, this is the sort of 'angels on the head of a pin' argument that
makes the standards community look like squabbling ivory tower idiots to
the user community.  I don't know who the audience is for the spec in
question, but it clearly is not users.  The language is Byzantine.

30 years ago I complained that a section of the ANSI C standard was hard to
understand because the language was stilted seemed ambiguous to me. I was
told 'a complete reading of the document will render full understanding of
this issue'.
Instead of debating whether the spec could be interpreted as saying what we
know it should say, wouldn't it be better to fix it so we don't get the
same question from another well-intentioned user at some point in the
future?  Or put a disclaimer on the front that says "don't try to
understand this.  You're not qualified." Whichever.
On Nov 30, 2013 11:16 AM, "Michael[tm] Smith" <mike@w3.org> wrote:

> Jukka K. Korpela" <jkorpela@cs.tut.fi>, 2013-11-30 15:40 +0200:
>
> > 2013-11-30 14:45, Michael[tm] Smith wrote:
> >
> > >>Maybe I missed something; where does "URL Living Standard" say
> something
> > >>about stripping line breaks?
> > >
> > >The parts of the algorithms where U+000A and U+000D are handled
> >
> > It says in different contexts that U+000A and U+000D cause “parse error”.
>
> It says more than that
>
> > In normal spec parlance, that would mean that the input does not
> > constitute a URL;
>
> I guess that depends on what specs you're accustomed to reading.
> But anyway it doesn't mean that parsing fails.
>
> > here it is pseudo-defined by saying this: “A parse error indicates a
> > non-fatal mismatch between input and requirements. User agents are
> > encouraged to expose parse errors somehow.”
>
> Consistent with how the HTML spec defines parse errors.
>
> > If the intent is that the offending character is just ignored, then this
> > should be said.
>
> It is said.
>
> If you follow the algorithms, it's clear what happens with U+000A and
> U+000D
> (they don't get appended to the buffer the parsed URL is formed from).
>
> > I think the normal interpretation is that “parse error” terminates
> > parsing,
>
> Only if by normal you mean XML
>
> The URL spec calls them "parse errors" not "parse failures". It doesn't say
> they're fatal. It doesn't say to fail, abort, stop parsing or otherwise do
> some kind of early return due to them.
>
> > or at least means that parsing cannot return a valid item.
>
> Validity isn't relevant to the output that gets returned from URL parsing.
> The
> parsing either succeeds and returns a URL object, or it fails.
>
> --
> Michael[tm] Smith http://people.w3.org/mike
>
>