CustomXmlPart - setData(byte[] value) & setId(java.lang.String value)

Hi there,
We are curious to know -
#1. Why Aspose allows non-xml data passed as a byte[] to be stored in custom xml file. Since this would corrupts the word document. Why API is not throwing IllegalArgumentException. Is there any reason for this? Is the behavior helpful in some scenarios. If yes please help us to see the same scenarios.

#2. Why Aspose allows to set the id as any String value. We think that any String value would not corrupts the word document but to manipulate the word document from other Office APIs the id should have {} (curly braces) and something like - “{” + UUID.randomUUID().toString().toUpperCase() + “}” ({3BC85265-09D6-4205-B665-8EB239A8B9A1}). Why there is no check for the valid GUID for the custom xml part. Is there any reason for this? Is the behavior helpful in some scenarios. If yes please help us to see the same scenarios.

Thanks.

Hi Praneeth,

Thanks for your inquiry. Regarding #1, please share your code here for testing. We will investigate the issue on our end and provide you more information. Regarding #2, we are in communication with our development team and will update you as soon as we have any further information.

Best regards,

Hi Awais,

String xmlData = "non xml data"; 
byte[] bytes = xmlData .getBytes();

CustomXmlPart myXml = new CustomXmlPart();
myXml.setData(bytes);
myXml.setId("nonWordStandardId");
doc1.getCustomXmlParts().add(myXml);

finally after saving doc1, non-xml data would corrupts the file but id wouldn’t corrupts the file but is not valid according to standards.

Hi Praneeth,

Thanks for the additional information. I tested the scenario and have managed to reproduce the same problem on my side. For the sake of correction, I have logged this problem in our issue tracking system as WORDSNET-9970. Our development team will further look into the details of this problem and we will keep you updated on the status of correction. We apologize for your inconvenience.

Best regards,

Hi Praneeth,

Praneeth:
#2. Why Aspose allows to set the id as any String value. We think that any String value would not corrupts the word document but to manipulate the word document from other Office APIs the id should have {} (curly braces) and something like - “{” + UUID.randomUUID().toString().toUpperCase() + “}” ({3BC85265-09D6-4205-B665-8EB239A8B9A1}). Why there is no check for the valid GUID for the custom xml part. Is there any reason for this? Is the behavior helpful in some scenarios. If yes please help us to see the same scenarios.
Thanks for reporting this problem to us. In this case, we provide bare minimum that allows the customers to get the job done. I think older versions of Microsoft Word followed the same strategy as well. We used Microsoft Word 2007 pre SP1 during reference implementation to do the sanity test. Sometimes we use requirements that are less strict than specifications say in order to adhere to Microsoft Word behavior.

Your concern are valid and now that Microsoft Word implementation has grown more strict, we will look into it sometime in the future during one of the CustomXML API updates. We have logged a new issue in our issue tracking system. The ID of this issue is WORDSNET-10021. Your request has also been linked to this issue and you will be notified as soon as it is resolved. Sorry for the inconvenience.

Best regards,

The issues you have found earlier (filed as WORDSNET-9970) have been fixed in this Aspose.Words for .NET 18.6 update and this Aspose.Words for Java 18.6 update.

The issues you have found earlier (filed as ) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by MuzammilKhan

The issues you have found earlier (filed as WORDSNET-10021) have been fixed in this Aspose.Words for .NET 21.5 update and this Aspose.Words for Java 21.5 update.