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

From: Michael[tm] Smith <mike@w3.org>
Date: Fri, 29 Nov 2013 14:12:22 +0900
 > So to make them valid URLs you need make each of your "data"
 > attribute values a single line, without the line breaks.

Raveling base64 data is ugly but not difficult.  Thanks
for the help.

With very limited knowledge of the protocols, these comments
might be misguided.  Certainly offence is not intended.
Trying to be honest.

From: Philip Taylor <P.Taylor@Rhul.Ac.Uk>
Date: Fri, 29 Nov 2013 09:54:05 +0000
 > ... a data URI ...

Data and an identifier of data are distinct concepts.

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Fri, 29 Nov 2013 13:48:09 +0200
 > ... removing line breaks is OK since URLs must not contain line breaks.

Originally a reasonable constraint.  The advent of
URIs too wide for commonplace displays made it troublesome.
I'm not aware of any significant proposal to remove the
constraint or otherwise resolve the difficulty.

 > It's a bit different with spaces.
 > ... in a data: URL, they seem to get ignored.

A stream of data needs either a specification of length or
an end mark.  Beyond specifying where data begins and ends,
a further constraint is unnecessary and reduces efficiency.

 > ... it might be regarded as useful error recovery.

Error recovery is good.

I see two possibilities to improve the specification.
First the syntax should be defined in an EBNF.  Attempts
to define formal syntax in an natural language have
always led to ambiguity, confusion and inefficiency.
Certainly natural language is needed to explain semantics.

The distinction between data and URI should be acknowledged.
Data can contain a URI.  Seems possible for an object
element to have a data attribute.  That data might contain
a URI.  But why not have distinct data and URI attributes?

Make it as simple as possible, but not simpler.

Regards,             ... Peter E.

Received on Friday, 29 November 2013 16:05:44 UTC