Hello Youenn, Thanks for your input. See my responses below.
> Hi Daniel, Peter, > > There may be more to define than uploading a XML schema document. > You probably need to take care of all include/import in a proper way so that > everything is unambiguous. Correct. The next revision will include a method for how to create a "main schema" in an unambiguous way, that will import the schemas agreed on during schema negotiation. We're working on this revision. It will also include a new binary-only transport. > Uploading a compressed XML schema document give benefits on the network side > but it does not give any benefit on the processing side. Processing a schema > document is generally difficult and will probably be restricted to XMPP > servers? The schemas uploaded will probably be internal to the xmpp server and not used for other purposes than EXI compression/decompression. However, it's a good point. > Having a simpler format would help (better compression, better processing) > but would need some significant extra definition work. Do you know of any such formats? > As for QName and prefix preservation, whenever you have an attribute whose > type is QName, the whole attribute value is encoded as a string (except for > @xsi:type values). Therefore the decoder needs to know how to resolve the > prefix that is embedded in the string representation to a URI. > If preserving prefixes, you guarantee that the information is available to > the decoder. > But other alternatives, for instance conventions specifically defined to the > XMPP environment, may be envisioned. I think the solution of preserving prefixes during schema negotiation is a good choice and is easy to implement/understand. If you see better alternatives, please feel free to elaborate. > Regards, > Youenn Thanks again for your input, Sincerely, Peter Waher
