Author Topic: Support for additional XML parsers  (Read 6731 times)

smitchell

  • Community Member
  • Posts: 9
  • Hero Points: 0
Support for additional XML parsers
« on: November 12, 2007, 07:57:46 pm »
Hello,

I like to use Slickedit for editing XML - especially when a schema is available for context tagging. Recently, I have been authoring MSBuild project files which use Microsoft.Build.xsd. Unfortunately, Xerces generates several errors on this schema, which do not appear if the MSXML parser is used (verified with Oxygen XML editor 9.0).

It is probably wishful thinking, but is it possible to make some "simple" mods to my configuration to change the XML parser from Xerces to MSXML? If not, is that something that might be considered for a future release?

Thanks,
Stan Mitchell
SourceQuest, Inc.

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: Support for additional XML parsers
« Reply #1 on: November 13, 2007, 09:47:14 pm »
What version of SlickEdit are you using? There have been some improvements in the 12.0.x (SE 2007) versions.

What I find helps most for editing MSBuild .proj files is to make sure you have an updated URL mapping for the http://schemas.microsoft.com/developer/msbuild/2003 namespace. Since there is no "real" xsd file at that URL location, SlickEdit can't download and reference it.

Go to Tools > Options > URL Mappings, and map the following:
From: http://schemas.microsoft.com/developer/msbuild/2003
To: C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas\1033\MSBuild\Microsoft.Build.Commontypes.xsd
(Or whatever path your Visual Studio is installed to)

You may need to close and reopen the files for the mapping to take hold.

Also, sometimes Visual Studio gets all "Unicode GungHo", and starts saving project files in Unicode or UTF-8 format, including the signature. Sometimes when SE loads an XML file (like a .csproj file) that has this mark, it gets confused and displays the leading EFBBBF signature as the literal characters .
I just delete the characters, and do a "Save As...", and pick "UTF-8, No Signature" in the encoding.
« Last Edit: November 13, 2007, 09:50:06 pm by Matthew »

smitchell

  • Community Member
  • Posts: 9
  • Hero Points: 0
Re: Support for additional XML parsers
« Reply #2 on: November 14, 2007, 05:20:18 pm »
Hi Mathew. Thanks for your reply.

My version of Slickedit (for Windows) is 12.0.3.0

My URL Mappings entry for MSBuild is as follows:
http://schemas.microsoft.com/developer/msbuild/2003
-->
D:\SourceUSB-2_10_01\SourceUSB\Build\MSBuild-Xml\Microsoft.Build.xsd

Microsoft.Build.xsd includes two additional schema files in the MSBuild subdirectory.

The errors that I see come from Microsoft.Build.CommonTypes.xsd and are as follows:

File D:\SourceUSB-2_10_01\SourceUSB/Build/MSBuild-Xml/MSBuild\Microsoft.Build.CommonTypes.xsd
  16 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  67 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  136 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  167 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  199 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  240 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  290 57: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.
  398 61: Error Attribute 'Include' already defined in base and should not appear in derivation by extension.

Oxygen XML editor 9.0 allows the use of different XML parsers for validation. If I use Xerces, I see the same errors with it as with Slickedit, but if I change the parser to MSXML or MSXML.NET, validation succeeds.

Perhaps there is a Xerces setting that could be changed to allow it to accept this schema.


Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: Support for additional XML parsers
« Reply #3 on: November 14, 2007, 05:59:01 pm »
To answer your original question, we don't have a pluggable architecture for swapping out XML parsers. Xerces is "baked in" since we have to support multiple platforms.

I'm not seeing the errors you describe, but our MSBuild XML sources may be different. Under the Visual Studio 2005 XML directory, I have the following:
Schemas\1033\Microsoft.Build.xsd
Schemas\1033\MSBuild\Microsoft.Build.Commontypes.xsd
Schemas\1033\MSBuild\Microsoft.Build.Core.xsd

The top-level Microsoft.Build.xsd simply includes the M.B.Commontypes.xsd, and Commontypes includes M.B.Core.xsd. If I map to the top-level file, I don't get any validation errors, but I somehow lose the document root collection node definitions (like ItemGroup and PropertyGroup). If I map (like I showed earlier) to Commontypes, then I get all the definitions, and no validation errors.

If I copy all three files to the same directory, map to Microsoft.Build.xsd (and edit Microsoft.Build.xsd to not use the MSBuild\ relative path for the include), then all of the definitions are found correctly and no validation errors.

Maybe Xerces doesn't like that double-include with a relative path thrown in the mix.

smitchell

  • Community Member
  • Posts: 9
  • Hero Points: 0
Re: Support for additional XML parsers
« Reply #4 on: November 14, 2007, 08:01:55 pm »
We are using the same MSBuild schema - mine also comes from the directories you listed for Visual Studio 2005. However, my MSBuild project files have more verbose namespace information, like this:

<Project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://schemas.microsoft.com/developer/msbuild/2003 ../../Build/MSBuild-Xml/Microsoft.Build.xsd"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Rebuild"
  InitialTargets="ValidateCommandLine">

I have been using this format because other XML editors use the schemaLocation to perform the equivalent of URL Mappings. If I reduce this to the short form:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Rebuild"
  InitialTargets="ValidateCommandLine">

then the errors go away. However, that may break my other XML editor - I'll need to investigate.



Regarding which schema to map to, M.B.xsd vs M.B.Commontypes.xsd, is more clear cut in my case. I need to map to the top level M.B.xsd, because I have defined custom tasks, item groups, and property groups in this file. But your suggestion to place all of the xsd files in the same directory seems to work around this issue.

Thanks for your help,
-Stan





smitchell

  • Community Member
  • Posts: 9
  • Hero Points: 0
Re: Support for additional XML parsers
« Reply #5 on: November 15, 2007, 04:43:01 pm »
Just a quick follow up after making the changes discussed previously.

The short form XML header will also work with Oxygen XML 9.0 editor by using document type association, i.e. associating file extension with a schema in a project.

Now, I am seeing a different problem. Slickedit's XML Validation comes back with "Document is Valid" although I know it has invalid child elements under PropertyGroup and ItemGroup elements. However, the context tagging is working ok.

Is there a way to display schema annotations/documention for a tag? In the preview window the Comments area is always blank.

Thanks,
-Stan

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
Re: Support for additional XML parsers
« Reply #6 on: November 15, 2007, 09:08:32 pm »
I'll check what the feature request status is for XML support.  Adding comment preview, and supporting xsi::schemaLocation sound like pretty useful features.