Re: What to do about newlines in attribute values?

On Thu, Sep 13, 2012 at 1:25 PM, Liam R E Quin <liam@w3.org> wrote:

> On Thu, 2012-09-13 at 08:45 -0600, Uche Ogbuji wrote:
> > On Thu, Sep 13, 2012 at 12:48 AM, John Cowan <cowan@mercury.ccil.org>
> wrote:
> >
> > > James Clark scripsit:
>
> > > > c) allow newlines but don't normalize them: most useful behaviour but
> > > > incompatible with XML
> > >
> > > And therefore a non-starter.
> > >
> >
> > I'm not so sure about this.  As I have understood it the backward
> > compatibility goal is satisfied as long as every MicroXML document is a
> > well-formed XML document.
>
> You have to go beyond that and ask why that's a goal.
>
> If you expect to replace tool chains altogether then the compatibility
> is for comfort and familiarity only.
>
> If you want to use XML tools with µXML, the compatibility has to be all
> the way through o the data model.
>

Well it's my turn to say you have to examine this statement further.  You
can certainly use XML tools with MicroXML even if there are differences in
the data model.  Obviously these will simply lead to differences in
processing.  It is up to the user of the tools to anticipate or deal with
such differences.  If the differences are large and easily encountered in
commonplace cases, I think that would be a problem.  But in the sort of
case we are discussing at present, the difference is so minuscule in
practice that I believe it is quite acceptable.  Developers do have to be
aware of the difference in processing, but as pointed out earlier, the same
difference in behavior has existed in the case of HTML and the behavior of
newlines in certain constructs, and there has hardly been chaos from such
differences.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji

Received on Thursday, 13 September 2012 19:52:15 UTC