Spam: Re: [Mono-devel-list] minor xslttest makefile patch

[Atsushi Eno]

Hi Andrew,

Andrew Skiba wrote:
> Atsushi Eno wrote:
>> Well, it is not analysis ;) Any progress or difficulty on fixage?
> 
> The old testsuite reported some regressions when .net throws an 
> exception. I think, we can ignore them for now.

Are they really such testcases? I think those tests listed up
there are bug in your sed script. The previous catalog.xml which
I manually edited was pointing to the correct file names. Just
compare old catalog.xml and your catalog-fixed.xml.

>>>  > XSLTFunctions_RoundTripNumber_UsingStringFn
> ...
>> As for XSLTFunctions_RoundTripNumber_UsingStringFn, there seems
>> different behavior on decimal roundtrip formatting. I remember
>> (and have) your patch for that case, which is sadly still not
>> working. I'll dig into it later.
> 
> Here we have 3 choices: commit it to mono, make it TARGET_JVM or add the 
> test to knownFailures. Probably I'm not the right person to decide 
> between the last 2, and the first depends on you.

If the patched version works fine, then let's just check it in w/
TARGET_JVM with comments.

>  > Here is the related part of the spec I think:
>>
>>     The html output method should output boolean attributes
>>     (that is attributes with only a single allowed value that
>>     is equal to the name of the attribute) in minimized form.
> 
> I notice "only a single allowed value" - so value of selected="foo" is 
> not allowed. What you want to do in such case? Silently ignore the value 
> (as you did), output it when it's different from the usual (as MS does) 
> or throw an exception? I think that I will agree to any solution. I did 
> my investigation before I saw your patch.

Well, the type of an attribute does not vary depending on the value
string (well, am sure that this is true to XML but not sure when it
comes to HTML so correct me if it sounds wrong). So "selected"
attribute is always boolean.

Note that it does not say boolean attribute "value". And even in
case of invalid value in HTML specification, XSLT specification
does not require the implementation to raise an error.

So, not throwing an error and just minimizing the value is what
I thought best conformance.

Besides the specification I tend to agree your idea to fix it.
It sometimes might happen to keep those "not-allowed" value
for some kind of post-processing on users side, and eliminating
such values will slightly make sense (unless there is extremely-
strict HTML implementation).

> Regarding the off-topic discussion on string comparison, we always 
> compare with 2 pre-defined english words - is culture info relevant in 
> such cases?

Am not sure what you mean "pre-defined english words", but as I
wrote to Kornél, String.Compare() is culture dependent (unless
you use CompareOptions.Ordinal).

> We have also some Xalan tests regressed, if you are interested to 
> analyse them, too, I would appretiate.

Let's put it on our table :-)

Atsushi Eno