![]() |
Telelogic System Architect (steve huntington) | ![]() |
Topic Title: XML does not validate against DTD Topic Summary: The XML Generated by SA does not validate against SAXML.DTD Created On: 25-May-2006 12:23 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I've already got an enhancement request in for the UTF-8/UTF-16 problem and an case in for the other parts but I thought that others may benefit from this information.
You can find the SAXML.DTD in your SA Installation directory. From my experience, the XML generated by SA does not validate against the DTD that is provided in several ways, which I have outlined below: 1) The DTD calls for UTF-8 while the XML files uses UTF-16. 2) The new DTD that came with v10.4.13 (and maybe v10.3) replaced the "Classes" element with the "SAEncyclopedia" element and the "Class" element with the "SAContent" element. The XML files still reference the old "Classes" and "Class"elements. 3) At least one attribute so far was added to the XML that has not been added to the DTD. That is the "SADgmWLinePenStyle" attribute of the "SADiagram" element. [update] SALocType is missing from the SALocAtt list. So far, I think editing the DTD manually will suffice but it would certainly be nice in the future if the XML validates against the DTD. I'll post updates if I find more inconsistencies. At least knowing about them can help when working with the XML. Edited: 25-May-2006 at 12:52 by Jonathan Burlingame |
|
![]() |
|
![]() |
|
I was informed that the SAXML.DTD that is in the SA directory is not used by SA but rather it uses an internal DTD. This is to prevent the user from making changes and crippling the application or damaging the data. I assumed that the DTD that was in the directory was NOT read by SA but rather was an exact replica of what it uses internally. The technician I spoke with was unclear if that was the case.
They have submitted an enhancement request to have the DTD file used internally by SA to be released if it is different, and in either case have it updated to match the XML it generates. I already had another enhancement request in to have the DTD encoded to UTF-16 since that is what the generated XML is formatted in. I was able to hack the DTD to get it to validate against the XML I am generating so far. It wasn't difficult however hopefully in the future they will release a compliant DTD to remove this requirement. |
|
![]() |
|
![]() |
|
Jonathan,
|
|
![]() |
|
![]() |
|
Well, it is true that getXML doesn't give the same information exactly, that Export XML does from the menu item. For instance, the Export XML function removes duplicate entries from the resulting XML file. However, I ended up creating a class that exports the requested XML, removes duplicates, and formats the XML to actually look decent to take care of that problem.
The problem I having is that the XML from either source is not 100% compliant with the supplied DTD. This is creating an issue for me because when I feed the XML to another application along with the DTD, the XML fails validation and is ignored. In applications that I have written I can work around this by relaxing the strictness so to speak, but in applications that are not written by me and closed source, I'm force to massage the XML and/or the DTD to make it compliant. If SA had a complete DTD And the XML generated was 100% compliant with that DTD, it would make life a bit easier. |
|
![]() |
|
![]() |
|
Jonathan, |
|
![]() |
|
![]() |
|
Well, I have two potential problems here. For one, I'm not sure I can share the code since it may fall under proprietary classification, so I'll have to look into that. Secondly, I am working C#, using COM to interface with SA. I'm not a huge fan of VBA for a number of reasons, so I've done most all of my extensions and interfaces using C# & COM.
|
|
![]() |
|
![]() |
|
That is ultimately direction I am heading as well. VBA is not the ultimate solution. We are going to build a Web Service for SA for integration with other platforms (capital planning, workforce planning, etc.). I do understand some code may be proprietary, so no hard feelings. I am just hoping to leverage efforts of others that are heading down the same path.
Bill |
|
![]() |
|
![]() |
|
I can definitely appreciate wanting to leverage existing efforts as much as possible. Thus far the only thing I have had to go on are the existing macros and any past code I myself have written. It would be great to have some public non-trivial works both to use and to have as reference.
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.