Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove erroneous curlies in Xml resource #33890

Merged
merged 33 commits into from
Apr 18, 2020
Merged

Remove erroneous curlies in Xml resource #33890

merged 33 commits into from
Apr 18, 2020

Conversation

mrj001
Copy link
Contributor

@mrj001 mrj001 commented Mar 20, 2020

This is addressing one of the 13 strings in issue 30218 that have faulty formatters (Sch_MinLengthGtBaseMinLength). I'd like some feedback on this approach before I tackle the other 12.

@dnfclas
Copy link

dnfclas commented Mar 20, 2020

CLA assistant check
All CLA requirements met.

Copy link
Member

@danmoseley danmoseley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good but I would either change the test to be locale-independent, or (if there's already functional coverage) consider not bothering with a test at all. This would be acceptable for any cases where you are literally just changing the text of the string and there are no replacement parameters in it.

@danmoseley
Copy link
Member

Looks like test failures are unrelated - if you push your edit, it will run again.

BTW, we prefer to set the PR title to something that mentions to issue, not a number.

@danmoseley danmoseley changed the title Issue30218 Remove erroneous curlies in Xml resource Mar 20, 2020
@mrj001
Copy link
Contributor Author

mrj001 commented Mar 30, 2020

@danmosemsft
Sorry it took so long to get back to this. I was blocked on trying to generate the code coverage report. Finally gave up and filed #34152 . How does one determine the code coverage with coverlet?

Since I don't have this information, I've decided to proceed with unit tests. I suspect that if unit tests did cover these strings, they would have had proper formatters in them. Also, it confirms to me that I understand exactly when these are being used.

In looking at Sch_LengthGtBaseLength, I have come up with two questions. This resource is only used in method CompileLengthFacet in file FacetChecker.cs:

                if ((_baseFixedFlags & RestrictionFlags.Length) != 0)
                {    
                    if (!_datatype.IsEqual(_datatype.Restriction.Length, _derivedRestriction.Length))
                    {    
                        throw new XmlSchemaException(SR.Sch_FacetBaseFixed, facet);
                    }    
                }    
                if ((_baseFlags & RestrictionFlags.Length) != 0)
                {    
                    if (_datatype.Restriction.Length < _derivedRestriction.Length)
                    {    
                        throw new XmlSchemaException(SR.Sch_LengthGtBaseLength, facet);
                    }    
                }    

I can trigger the exception to throw with the message SR.Sch_LengthGtBaseLength by specifying a length facet in both a base type and a derived type, with the derived type having a longer length.

Q1: Isn't the length facet supposed to specify the exact length? If so, why is the second test above checking for "less than" rather than "not equal"?
Q2: what is _baseFixedFlags vs. _baseFlags? The first test was not triggered by my test case, but the second one was. I'm curious as to why I'm not triggering the first test.

This is the test schema that I use to provoke the exception.

<?xml version='1.0' encoding='utf-8' ?>
<xs:schema elementFormDefault='qualified'
           xmlns:xs='http://www.w3.org/2001/XMLSchema'>
    <xs:simpleType name='foo'>
        <xs:restriction base='xs:string'>
            <xs:length value='5'/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name='bar'>
        <xs:restriction base='foo'>
            <xs:length value='6'/>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

@danmoseley
Copy link
Member

@mrj001 are the instructions in https://github.com/dotnet/runtime/blob/master/docs/workflow/building/libraries/code-coverage.md not working? If not @ViktorHofer owns them.

For your other questions, @buyaa-n owns System.Xml and can help.

@buyaa-n
Copy link
Contributor

buyaa-n commented Mar 31, 2020

Q1: Isn't the length facet supposed to specify the exact length?

Yes, but only for that type i assume (in this case the base type)

If so, why is the second test above checking for "less than" rather than "not equal"?

Because derived type can have length less than or equal to base type length, why do you think it must be equal?

Q2: what is _baseFixedFlags vs. _baseFlags?

Looks _baseFixedFlags is for only inferring if base type is fixed (which can be a boolean), but _baseFlags has RestrictionFlags of base (Length, MinLength, MaxLength ... etc)

The first test was not triggered by my test case, but the second one was. I'm curious as to why I'm not triggering the first test.

I assume you need to set fixed value for base type definition for example:
<xs:simpleType name='foo' type="xs:string" fixed="FixedValue">

@mrj001
Copy link
Contributor Author

mrj001 commented Mar 31, 2020

@buyaa-n

Because derived type can have length less than or equal to base type length, why do you think it must be equal?

I initially relied on this page's description:
https://www.w3schools.com/xml/schema_facets.asp
A derived type would fail the "Is A" test if its length were different from that of its base class.

For greater surety, see the note in paragraph 4.3.1.1 of:
https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html

In Paragraph 4.3.1.4 of the same link:

Schema Component Constraint: length valid restriction
It is an ·error· if length is among the members of {facets} of {base type definition} and {value} is not equal to the {value} of the parent length.

And a unit test (failing) to demonstrate. Shall I file a separate issue? This is getting off topic of this pull request.

        [Fact]
        public void LengthLtBaseLength_Throws()
        {
            string schema = @"<?xml version='1.0' encoding='utf-8' ?>
<xs:schema elementFormDefault='qualified'
           xmlns:xs='http://www.w3.org/2001/XMLSchema'>
    <xs:simpleType name='foo'>
        <xs:restriction base='xs:string'>
            <xs:length value='7'/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name='bar'>
        <xs:restriction base='foo'>
            <xs:length value='6'/>
        </xs:restriction>
    </xs:simpleType>
</xs:schema>
";

            XmlSchemaSet ss = new XmlSchemaSet();
            ss.Add(null, XmlReader.Create(new StringReader(schema)));

            Exception ex = Assert.Throws<XmlSchemaException>(() => ss.Compile());
            Assert.Contains("length", ex.Message);
        }

editted to fix hyperlinks.

@buyaa-n
Copy link
Contributor

buyaa-n commented Mar 31, 2020

Schema Component Constraint: length valid restriction
It is an ·error· if length is among the members of {facets} of {base type definition} and {value} is not equal to the {value} of the parent length.

I think that is valid only for fixed length:
image

That is why we have this condition:

if ((_baseFixedFlags & RestrictionFlags.Length) != 0)
{    
    if (!_datatype.IsEqual(_datatype.Restriction.Length, _derivedRestriction.Length))
    {    
        throw new XmlSchemaException(SR.Sch_FacetBaseFixed, facet);
    }    
} 

@buyaa-n
Copy link
Contributor

buyaa-n commented Mar 31, 2020

And a unit test (failing) to demonstrate. Shall I file a separate issue? This is getting off topic of this pull request.

By counting my above comment your test should fail unless it has fixed = true attibute. So this is valid scenario, no need to file issue

@mrj001
Copy link
Contributor Author

mrj001 commented Mar 31, 2020

@buyaa-n
This is the note from Paragraph 4.3.1.1 (emphasis added):

Note: The {fixed} property is defined for parallelism with other facets and for compatibility with version 1.0 of this specification. But it is a consequence of length valid restriction (§4.3.1.4) that the value of the length facet cannot be changed, regardless of whether {fixed} is true or false.

@buyaa-n
Copy link
Contributor

buyaa-n commented Mar 31, 2020

Note: The {fixed} property is defined for parallelism with other facets and for compatibility with version 1.0 of this specification. But it is a consequence of length valid restriction (§4.3.1.4) that the value of the length facet cannot be changed, regardless of whether {fixed} is true or false.

@mrj001 that is good point, I understand and really appreciate your effort for trying to make this right, but FYI we only support version 1.0

mrj001 added 20 commits April 15, 2020 09:08
…dded the name of the element which cannot be used as the substitution group affiliation.
…string resource Sch_GroupBaseRestNotEmptiable as its message.
…string resource Sch_AllRefMinMax as its message.
@buyaa-n
Copy link
Contributor

buyaa-n commented Apr 18, 2020

Looks good but I would either change the test to be locale-independent, or (if there's already functional coverage) consider not bothering with a test at all. This would be acceptable for any cases where you are literally just changing the text of the string and there are no replacement parameters in it.

@danmosemsft I think @mrj001 addressed your change request, tests added using schema attribute names instead of entire error messages as string literal, tests looks good and improving code coverage, do you have any other comments/suggestions?

Tagging also @krwq as he is back

@danmoseley
Copy link
Member

@buyaa-n don't wait on me, I trust your review

@buyaa-n
Copy link
Contributor

buyaa-n commented Apr 18, 2020

@buyaa-n don't wait on me, I trust your review

Thanks, as you have requested change we still need your approval 😄, the merge button still disabled for me

@danmoseley
Copy link
Member

Oops, done

@danmoseley danmoseley merged commit 9e9543b into dotnet:master Apr 18, 2020
@danmoseley
Copy link
Member

danmoseley commented Apr 18, 2020

Thank you @mrj001 for the contribution. Perhaps you'd be interested in looking at another issue that is labeled up for grabs.

@krwq
Copy link
Member

krwq commented Apr 20, 2020

LGTM post merge

@mrj001 mrj001 deleted the Issue30218 branch April 20, 2020 21:15
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants