System.Xml의 새로운 기능
.NET Framework의 System.Xml에 XmlConvert 메서드라는 새로운 기능이 추가되어 W3C Fourth Edition을 지원합니다.
XmlConvert 메서드 추가
XmlConvert 클래스의 새 멤버를 사용하면 다음과 같이 특정 문자 및 문자열을 특정 XML 토큰 또는 유효한 XML로 확인할 수 있습니다.
public static bool IsNCNameChar(char);
public static bool IsPublicIdChar(char);
public static bool IsStartNCNameChar(char);
public static bool IsWhitespaceChar(char);
public static bool IsXmlChar(char);
public static bool IsXmlSurrogatePair(char, char);
public static string VerifyPublicId(string);
public static string VerifyWhitespace(string);
public static string VerifyXmlChars(string);
Visual Studio 2010의 주요 변경 내용
다음 단원에서는 System.Xml의 주요 변경 내용에 대해 설명합니다.
XML 관련 클래스의 NullRefenceException 변경
스타일시트를 로드할 때 XslCompiledTransform 클래스에서 NullReferenceException을 throw할 수 있었습니다.
XmlNode.InnerText에서 NullReferenceException을 throw할 수 있었습니다.
생성자에 대한 일부 인수가 null인 경우 XmlValidatingReader 클래스에서 NullReferenceException을 throw할 수 있었습니다.
이제 이러한 경우에 대해 좀 더 유용한 예외를 throw하고 코드를 쉽게 디버깅할 수 있도록 변경되었습니다.
XmlWriter.Dispose에서 모든 예외 표시
이전에는 XmlWriter.Dispose에서 OutOfMemoryException과 같이 catch하지 않아야 하는 예외를 포함하여 모든 예외를 표시하지 않았습니다.이제 XmlWriter.Dispose에서 유용한 예외를 throw하도록 변경되었습니다.
여러 스키마에 의해 포함되는 경우 카멜레온 스키마가 올바르게 복제됨
대상 네임스페이스가 없는 스키마, 즉 카멜레온 스키마의 경우 이전에는 공용 형식을 스키마에 포함했지만 이제는 다른 XSD에 포함될 경우 가져오는 스키마의 대상 네임스페이스를 사용합니다.
XmlSchemaSet에 두 개의 스키마가 있고 두 스키마 모두 카멜레온 스키마를 포함하는 경우 카멜레온 스키마가 두 스키마에 올바르게 복제되지 않았습니다.이 문제는 XML 유효성 검사에 영향을 주고잘못된 유효성 검사로 인해 데이터가 손상될 수 있었습니다.
그러나 이제는 아무 문제 없이 복제가 진행됩니다.
MoveToAttribute(Int32)를 호출한 후 XsdValidatingReader.MoveToNextAttribute가 올바르게 작동됨
XsdValidatingReader.MoveToAttribute(Int32)의 버그 때문에 현재 특성 인덱스가 업데이트되지 않아 MoveToNextAttribute가 실패했습니다.이로 인해 XsdReader의 다양한 서브클래스에 대해 다형성을 사용하지 못했습니다.
이제는 MoveToAttribute(Int32)를 호출한 후에도 XsdValidatingReader.MoveToNextAttribute가 올바르게 작동합니다.
전달된 IxmlNamespaceResolver가 XmlReader.ReadContentAs에서 무시되지 않음
이제는 IxmlNamespaceResolver를 받는 XmlReader.ReadContentAs 메서드가 IXmlNamespaceResolver 매개 변수를 네임스페이스 확인자로 사용합니다.이전에는 IXmlNamespaceResolver 매개 변수가 무시되었고 XmlReader가 네임스페이스 확인자로 사용되었습니다.
테스트할 함수가 호출되지 않은 경우에도 Function-available XSLT 함수를 사용할 수 있음
function-available 함수는 특정 이름의 함수를 사용할 수 있는지 여부를 확인하는 데 사용됩니다.이전에는 XSLT에서 함수가 호출되지 않은 경우 해당 함수를 사용할 수 있더라도 function-available 함수에서 항상 false를 반환했습니다.이 오류는 MSXML3 SP1에서 수정되었습니다.
XmlSchemaSet의 종속성 버그가 수정됨
XmlSchemaSet을 사용하면 XSD 스키마를 컴파일할 수 있습니다.이러한 스키마는 다른 스키마를 포함할 수 있습니다. 예를 들어 A.xsd는 C.xsd를 포함할 수 있는 B.xsd를 포함할 수 있습니다.이러한 스키마를 컴파일하면 종속성 그래프가 트래버스됩니다.이전에는 집합의 스키마가 수정되고 종속된 스키마가 다시 컴파일되거나 다시 처리된 경우 스키마의 종속성 그래프가 올바르게 트래버스되지 않아 컴파일된 스키마의 일관성을 유지하지 못했습니다.
유효 공백을 잘못 삭제한 판독기가 XmlReader.Create에서 반환됨
XML 유효성 검사에서는 텍스트와 XML 태그를 포함하는 혼합 콘텐츠 모드를 인식합니다.혼합 모드에서는 모든 공백이 유효하므로 보고되어야 합니다.이전에는 XsdValidatingReader에서 유효 공백을 유효하지 않은 것으로 보고했습니다.
이로 인해 기본적으로 유효하지 않은 공백을 제거하는 XmlDocument 또는 XDocument/Xelement로 데이터가 로드되는 경우 데이터 손실이 발생했습니다.
래핑 XmlWriter에서 NewLineHandling.None을 고려하지 않음
다른 XmlWriter에 쓰는 래핑 XmlWriter를 만들고 래핑 XmlWriter에 NewLineHandling.None이 있다고 지정한 경우 WriteChars 메서드를 사용하면 콘텐츠에 /r/n이 포함되고 출력에 /r/n/r/n(데이터 손상)이 포함되었습니다.이 동작의 영향을 받는 두 가지 일반적인 시나리오가 있습니다.
XmlSerializer에서 만든 기존 XmlWriter를 사용한 다음, 해당 작성기를 래핑하는 경우.생성된 XML의 소비자가 공백을 허용하지 않는 경우(예: 타사 웹 서비스) 예기치 않은 동작이 발생할 수 있습니다.
XmlWriter를 사용하여 기존 XmlDocument 또는 Xdocument에 콘텐츠를 삽입하는 경우.이전에는 문서에 추가된 콘텐츠에서 줄 바꿈을 올바르게 표준화하지 못했습니다.
이제 이 문제가 수정되어 래핑 작성기에 대해 NewLineHandling.None이 올바르게 동작합니다.
XmlWriter의 XML 특성에서 엔터티 참조가 두 번 엔터티화됨
사용자가 XmlWriter.WriteEntityRef를 사용하여 xmlns 특성이나 xml:lang 또는 xml:space 특성에 엔터티를 작성한 경우 출력에서 엔터티가 두 번 엔터티화되어 데이터가 손상되었습니다.
XmlWriter w = XmlWriter.Create(Console.Out);
w.WriteDocType("root", null, null, "<!ENTITY e \"en-us\">");
w.WriteStartElement("root");
w.WriteStartAttribute("xml", "lang", null);
w.WriteEntityRef("e");
w.WriteEndAttribute();
w.WriteEndElement();
w.Close();
출력:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
예상:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
이제는 엔터티가 두 번 엔터티화되지 않습니다.
XNode.CreateReader에서 올바른 BaseURI가 반환됨
CreateReader를 사용하여 LINQ to XML 클래스에서 XmlReader 개체를 만든 경우 Read가 한 번 이상 호출될 때까지 판독기에서 올바른 BaseURI를 반환하지 않았습니다.따라서 Read를 처음 호출하기 전에 BaseURI 값의 영향을 받는 코드는 XmlReader를 다른 메서드에 전달하는 것처럼 다른 호출을 통해 또는 코드에서 직접 Read가 호출된 후 변경됩니다.
LINQ to XML에 XSLT를 사용하는 경우 XSLT ID 함수에서 올바른 값이 반환됨
CreateReader 함수를 사용하여 LINQ to XML 클래스에서 XmlReader를 만드는 경우 이 XmlReader가 XSLT에 전달되면 이전에는 XSLT의 ID 함수 인스턴스에서 null을 반환했습니다.Null은 ID 함수에 대한 올바른 반환 값이 아닙니다.ID 값이 null인 경우 영향을 받는 코드는 변경되어야 합니다.
DocumentXPathNavigator가 x:xmlns 특성의 로컬 이름을 올바르게 보고함
이전에는 DocumentXPathNavigator가 x:xmlns 특성의 로컬 이름에 대해 빈 문자열을 반환했습니다.이로 인해 데이터 손상이 발생하고 경우에 따라 XSLT를 사용하여 XSLT를 생성하지 못했습니다.
이제 로컬 이름이 올바르게 반환되어 XSLT, 다른 XSLT를 생성하는 코드 또는 x:xmlns 사용을 반환하는 문서를 사용할 수 있습니다.
XsltReader 및 하위 트리의 XmlReader가 한 XML 요소 내에 중복된 네임스페이스 선언을 만들지 않음
XsltReader를 사용하여 XSLT를 읽는 경우 XmlReader가 XsltReader에 배치되면 결과로 생성되는 XML 요소에 중복된 네임스페이스 선언이 포함되어 잘못된 XML이 만들어지고 일부 XML 프로세서와 관련된 문제가 발생했습니다.
이로 인해 데이터 손상이 발생하고 XmlReader에서 올바른 XML을 만들지 못했습니다.