I'll concur wrt the generality, flexibility, and power of XML as a data encoding. Considering comments on the ancestor thread, though, I'll also observe that the generality and flexibility are Not Your Friends if situations require encodings to be distinguished. The processing rules in X.690 that define DER relative to BER are expressed there within three pages (admittedly, excluding the cross-ref to X.680 for tag ordering); even though they may imply underlying complexity in implementation, their complexity in specification and concept seems vastly simpler than the issues that arise with XML canonicalization. --jl -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@xxxxxx] Sent: Wednesday, June 07, 2006 3:51 AM To: Hallam-Baker, Phillip Cc: ietf@xxxxxxxx Subject: Schema languages for XML (Was: Best practice for data encoding? On Tue, Jun 06, 2006 at 09:50:22AM -0700, Hallam-Baker, Phillip <pbaker@xxxxxxxxxxxx> wrote a message of 42 lines which said: > At this point XML is not a bad choice for data encoding. +1 > The problem in XML is that XML Schema was botched and in particular > namespaces and composition are botched. I think this could be fixed, > perhaps. There are other schema languages than the bloated W3C Schema. The most common is RelaxNG (http://www.relaxng.org/). In the IETF land, while RFC 3730 and 3981 unfortunately use W3C Schema, RFC 4287 uses RelaxNG. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf