>I simply do not agree that Mode 1 has any real utility. XML frameworks are by design flexible. If there is a need for backwards >compatibility then XSLT can be used to paper over any inconsistency. Viz Yes, it is always possible to use Transformations or other means to cater for any feature/function not supported directly by the encryption standard. So the question is really whether a feature should be mandated by the standard. If a commonly required feature is excluded we run the risk of losing inter-operability or efficiency (I assume a separate transform costs more). I am arguing for consistency of treatment. Sensitive data appear as attributes as frequently as in child nodes. Whether the standard addresses it or not, applications will have to address it one way or the other. >Case 2: > Message B states only that it is in schema PQR which is the standard schema for the application and incorporates the XML > encryption schema. The node encryption was considered at the time the schema was created. In this case, the schema designer, primarily an business expert, must also tale into account encryption requirements, sometimes there may be conflicting design goals. This assumption could be fraught with pitfalls. It may be better to keep security as "transparent" as possible.
Received on Monday, 8 January 2001 15:08:03 UTC