Re: Error recovery

On Sat, Nov 17, 2012 at 6:55 PM, James Clark <jjc@jclark.com> wrote:

> On Sun, Nov 18, 2012 at 7:21 AM, John Cowan <cowan@mercury.ccil.org>wrote:
>
>> James Clark scripsit:
>> I've found it useful to work with a generalization of the MicroXML data
>> model that does not restrict the characters that occur in names or in data.
>>  This is useful because you can use it to represent not only MicroXML but
>> also XML 1.0, XML 1.0 Fifth Edition, XML 1.1 and HTML, all of which have
>> slightly different restrictions on what are allowed in names or in data.
>>  You can also use this data model to represent the result of XML Namespaces
>> processing (by putting the URI in the name).
>>
>
> In implementation terms, the idea is to have a syntax-independent DOM,
> with just elements, attributes and characters. There are then separate
> parsers and serializers that convert between this DOM and various concrete
> syntaxes.  Different syntaxes will vary in which DOMs they can represent.
> It's the job of the serializer for a particular syntax to throw an error if
> it's given a DOM that the syntax cannot represent.  The MicroXML parser
> guarantees that it will produce such a DOM for any input.  It doesn't
> guarantee that the DOM can be serialized as valid MicroXML. Particularly
> for forbidden characters in attribute values and data, I think users will
> be much happier if the parser passes the characters through as is, instead
> of replacing them by some other character (although I do plan for to
> provide an option for the parser to perform replacement).
>
> I think there's something fundamental about the
> element/attributes/characters trinity as a data model for markup. I think
> this data model is of greater significance than the particular syntactic
> choices we've made in MicroXML.
>
> I also have a slightly subversive agenda for error recovery: I see it as a
> way to work around some of the annoying syntactic restrictions that XML
> compatibility has forced on MicroXML. I also hope to do is investigate
> alternative syntaxes for this data model that aren't constrained by
> compatibility with XML.
>
> I would like to change the Data Model section of the spec to separate out
> the aspects of the data model that are purely there as a result of the
> syntactic constraints of MicroXML.
>

I'll take some time to ponder the rest of the above, but as for the last
para, that seems a useful and certainly harmless update.

+1

-- 
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