[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XMLData problem in Core "Opaqueness
Hi Juan-Carlos et al, I made special provision to serialize rather than getContent on the XMLData node on both the client and server side, and it does work fine. So escaping is not abosultely necessary as you point out. However ... This line as well as PI specifications will also cause significant problems for many applications. e.g. <?xml version="1.0" encoding="UTF-8"?> This line if present in the XMLData document will not even get processed and will fail parsing for sure. I have checked into 2 popular XMLDSIG desktop solutions (Microsoft InfoPath in the Office 2003 being one of them) and they make use of Processing Instructions on the <?xml ...> line. Example: <?xml version="1.0" encoding="UTF-8"?> <?mso-infoPathSolution solutionVersion="1.0.0.1" productVersion="11.0.5531" PIVersion="1.0.0.0" href="....."?> <?mso-application progid="InfoPath.Document"?> These types of documents cannot have these lines removed. The application requires them. *** Additionally *** ... when passing in XMLData to be signed, if the test data has a <Document> node already in it you will get a parse error (... duplicate open tag encountered before close tag found ...) This would be true of <InputDocuments> as well. Any of our DSS elements which wrap the XMLData will be subject to this anomaly. It is not a huge issue, but "Document" is a pretty popular word !!! Implementations will therefore have to support some form of opaqueness in order to work properly. In fact the EPM Profile, for this and other reasons, forces the Base64Data choice of the DocumentBaseType to avoid all such XML nesting problems. These are significant restrictions that I believe should be addressed in the core. I had this debate long ago with Trevor when we were reviewing the EPM Profile. Perhaps we can add another choice for the DocumentBaseType. Something like "EncodedXMLData" with an attribute to specify which type of encoding is employed, and leave it open to implementers. (In fact DocumentBaseType could easily be extended to further collapse the excessive number of document/signature type elements we presently have i.e. Document, DocumentWithSignature, SignatureObject, UpdatedSignature, Timestamp, etc ...) Thoughts ? -----Original Message----- From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] Sent: April 7, 2005 12:50 PM To: ed.shallow@rogers.com Cc: 'Juan Carlos Cruellas'; 'OASIS DSS TC' Subject: Re: [dss] XMLData opaqueness ? Ed, see below, intermixed.... Edward Shallow wrote: >OK I'll try some other things. I can serialize at the node level so >handling this as staright XML is definitely doable, I just thought that >we might want to honor this escaping approach to really isolate the XMLData content. > I saw your point, and if you may ascertain that escaping a '<' in the middle of the contents of an element, the process by which you pass from the "escaped" xml document to the originial one still keeps the < in the middle of the contents of the aforementioned element, and if we may arrive to the conclusion that this is doable by all the parsers, then I think that we could consider this approach, otherwise, we could face different behaviour deppending of the tools. One of the things that I thought at first sigth was: "OK, for people that do not have exclusive canonicalization, tehre is always the posibility of b64-encode the xml docs, put them in the Base64 element and that is all about it....but still need to be sure that we are able to correctly deal with XMLData element contents.... > Did >not one of the public comments mention problems associated with >unwanted namespace inheritance from parent nodes in the request ? > > So far we have not received any other comment about that...I think that maybe one of the things that we should do is to test this feature in the interop and leave it documented..... Regards and sorry for replying so late (19:50 here)... Juan Carlos. >Ed > >-----Original Message----- >From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] >Sent: April 6, 2005 8:40 AM >Cc: 'OASIS DSS TC' >Subject: Re: [dss] XMLData opaqueness ? > >Ed, I am not familiar with the library you mention. >I know that there are others that seem to behave in different way. I am >using JDOM, for instance, and there if you add to an element a xml tree >as content, the '<' and the '>' are kept and you can see the tree >within the element. >Obviously this alternative would not allow to include the PI <?xml....> .... >What you mention seems to me as if you had ordered to the library to >add the XML document as TEXT content to the element, which forces the >escaping of all the '<' and '>'... and this brings me back to my >question: could you try to put within the xml document an element with >some text that has some < (ie an escaped '<') and then see if when >reading the parser is able to rebuild the original document? > >Juan Carlos. >Edward Shallow wrote: > > > >>Hi, >> >> I am bringing this up because this is exactly what my parser is doing >>(with encoding=None) when I build the XML request document. Because I >>am building by setting node content, the library (libxml2) knows what >>is structure and what is content. When I serialize the parsed object >>in order to prepare to send it to the DSS Server, it substitutes the >>escapes only in the node containing the XML content. >> >> My server happily parses the request (with the XML in the XMLData node). >>Then again I am using the same library on both sides. >> >> Rich ... Is escaped HTML valid in a UTF-8 encoded XML document ? Is >>the referenced escaping OK ? >> >>Cheers, >>Ed >> >>-----Original Message----- >>From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.edu] >>Sent: April 5, 2005 11:56 AM >>To: ed.shallow@rogers.com >>Cc: 'OASIS DSS TC' >>Subject: Re: [dss] XMLData opaqueness ? >> >>Ed, >> >>Your suggestion is to escape all the '<' and '>' so that in plain >>words, within <XMLData> there is not xml any more but a String coming >> >> >>from the serialization of a XML document or subtree where '<' and '>' > > >>have been escaped... >>I have a doubt: are we sure that any parser would be able to correctly >>undo the escape operations? I mean, what if within the original XML >>document there are '<' or '>' escaped documents as text (ie, as >>characters of the text content of certain elements)? >>Are we sure that the parser at the receiver will be able to >>distinguish which escaped characters will have to unescape? >> >>Juan Carlos. >> >>Edward Shallow wrote: >> >> >> >> >> > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in >OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in >OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]