Bug Triage #555555: scala.xml.parsing.MarkupParser always throws exception on syntax error

Alex Cruise schrieb:
> https://lampsvn.epfl.ch/trac/scala/ticket/745
>
> I'm inclined to call this enhancement a wontfix

At least this is how xml is intended to be processed. But trying to
discuss what to do about this might be the best way to stop this list
achieving anything.

Cf. http://diveintomark.org/archives/2004/01/16/draconianism

- Florian

On Wed, Feb 4, 2009 at 7:33 AM, Alex Cruise wrote:
> https://lampsvn.epfl.ch/trac/scala/ticket/745
>
> I'm inclined to call this enhancement a wontfix; MarkupParser doesn't claim
> to be fuzzy.
>
> Either that or de-prioritize it and retitle as something like "it sure would
> be nice to have a fuzzy parser" :)

I think you're right ... it should be a wontfix. If we fix this,

https://lampsvn.epfl.ch/trac/scala/ticket/1436

instead then we can get error-tolerant parsing from an alternative parser.

Cheers,

Miles

> At least this is how xml is intended to be processed.

Agreed. The XML libs provide a different way to handle XML, not a way
to handle a different XML. ;)

I vote wontfix also.

-m

On Feb 4, 2009, at 12:33 PM, Miles Sabin wrote:
> On Wed, Feb 4, 2009 at 7:33 AM, Alex Cruise
> wrote:
>> https://lampsvn.epfl.ch/trac/scala/ticket/745
>>
>> I'm inclined to call this enhancement a wontfix; MarkupParser
>> doesn't claim
>> to be fuzzy.
>>
>> Either that or de-prioritize it and retitle as something like "it
>> sure would
>> be nice to have a fuzzy parser" :)
>
> I think you're right ... it should be a wontfix. If we fix this,
>
> https://lampsvn.epfl.ch/trac/scala/ticket/1436
>
> instead then we can get error-tolerant parsing from an alternative
> parser.

I totally agree to Miles's argumentation.

Cheers,
--
Normen Müller

Florian Hars wrote:
> Alex Cruise schrieb:
>
>> I'm inclined to call this enhancement a wontfix
>>
> At least this is how xml is intended to be processed. But trying to
> discuss what to do about this might be the best way to stop this list
> achieving anything.
>
I don't disagree with the *idea* of a lax parser, I just don't think we
should make any attempt to add lax features to a strict parser that is
already working, and very likely in production use too.

If enough people are clamouring for a lax parser, someone can build one. :)
> Cf. http://diveintomark.org/archives/2004/01/16/draconianism
>
Tim's response
(http://www.tbray.org/ongoing/When/200x/2004/01/16/DraconianHistory) is
also interesting.

Thanks for your comments!

-0xe1a

Alex Cruise schrieb:
> If enough people are clamouring for a lax parser, someone can build one. :)

For HTML, I have done some experiments, see:
http://www.hars.de/2009/01/html-as-xml-in-scala.html

Of course this would be trivial with the proposed fix for
https://lampsvn.epfl.ch/trac/scala/ticket/1436
except maybe the handling of nodeContainsText through mixing in
the HTML specific logic (is nodeContainsText meant to be used
in this way?)

- Florian.

Quoting Florian Hars :

> Of course this would be trivial with the proposed fix for
> https://lampsvn.epfl.ch/trac/scala/ticket/1436
> except maybe the handling of nodeContainsText through mixing in
> the HTML specific logic (is nodeContainsText meant to be used
> in this way?)

Any specific opinions on Erik's patch? It seems straightforward to me.

-0xe1a

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Alex Cruise schrieb:
> Any specific opinions on Erik's patch? It seems straightforward to me.

Yes, it looks simple, straightforward and does what it claims to do.

My only qualms are an unspecified gut feeling that anything involving
NoBindingFactoryAdapter doesn't build on a finished design:

- if there is a NoBindingFactoryAdapter, was it intended to be
accompanied by a BindingFactoryAdapter that is just missing due to
lack of time or not?
- what is nodeContainsText good for if it is only ever stubbed out
with a trivial implementation with no framework in place to mix in
other versions?
- what is that hash-consing comment for:

39 /** creates a node. never creates the same node twice, using hash-consing
40 */
41 def createNode(pre:String, label: String, attrs: MetaData, scpe: NamespaceBinding, children: List[Node] ): Elem = {
42 //Console.println("NoBindingFactoryAdapter::createNode("+pre+","+label+","+attrs+","+scpe+","+children+")");
43 Elem( pre, label, attrs, scpe, children:_* );
44 //makeNode(pre, label, attrs, scpe, children);
45 }

But hte patch is independent from any cleanup that may or may not be
necessary here.

- Florian.

On Feb 5, 2009, at 8:15 AM, Alex Cruise wrote:
> Any specific opinions on Erik's patch? It seems straightforward to
> me.

+1

Cheers,
--
Normen Müller