html / xml language support

[Niko Sams]

On Wed, Jan 27, 2010 at 22:06, Ruan Strydom <ruan at jcell.co.za> wrote:
> Thank you for your input. Although I should not comment yet, as I have not
> done enough investigation yet, I have made "quements" ;) on some of the things
> bellow:
>
> Another question is SGML? Should I support it fully or only the quirks in HTML
> ie <br> <input> etc.? I honestly do not feel like throwing this into the mix
> as well?
>
> On Tuesday 26 January 2010 21:33:09 Bertjan Broeksema wrote:
>> On Tuesday 26 January 2010 20:07:11 Ruan Strydom wrote:
>> > > This solely depends on you. I'm not a really into XML, but isn't XSD
>> > > just XML? I.e. shouldn't a XML parser be able to handle XSD? DTD otoh
>> > > looks different, so probably needs it's own parser.
>> >
>> > The reason for giving XSD its own lexer/parser is because its a language
>> > on its own, XML is just the medium:
>> >
>> >   <xs:simpleType name="orderidtype">
>> >     <xs:restriction base="xs:string">
>> >       <xs:pattern value="[0-9]{6}"/>
>> >     </xs:restriction>
>> >   </xs:simpleType>
>> >
>> >
>> > so the lexer will break it up similar to html and xml but the parser will
>> >  have to handle simpleType with a special meaning, whereas <ns:order
>> >  orderType="" /> does not. In this case the orderType attribute is given
>> >  meaning by the simpleType declaration and by its inclusion.

Try to re-use as much existing solutions as possible.

You don't need to write your own lexer and parser for parsing XSD,
just use QXmlDom (or how it is called). With that you don't even need
your own Ast.

For parsing invalid xml (during editing or HTML) you could probably
look into QXmlStreamReder. At least as a starting point, future
versions could replace it with a even less restrictive parser.

As a first version you could for example implement just code
completion, without any duchain usage. That can come later.
Imho it's important to have something usable soon. Advanced features
can get added later.

Niko