Alessandro Triglia wrote:
-----Original Message-----
From: Stephen D. Williams [mailto:sdw@lig.net]
...
I mentioned XML consisting of idioms along with syntax and other
explicit standards. One powerful idiom that has become accepted and
expected with XML is that, whenever at all possible, you produce
precisely but accept loosely.
I think you are being too vague here. There must certainly be **rules** on
how and when you can be loose.
Yes, I was being vague. There is a certain accepted, but not
necessarily universally uniform or acceptable, range of looseness.
My interpretation of these:
If you expect an attribute "age", will you accept an attribute "Age"
instead?
No. Case insensitivity is so DOS. Good for DNS but little else.
If you expect an attribute "age", will you accept a child element <age>
instead?
Yes, in many applications I would write it this way. This allows me
brevity with an attribute and extensibility with an element tag.
Except for special-purpose attributes (ID, et al), this seems to make
sense to me in a general application sense.
If you expect an attribute "abc:age", will you accept an attribute "age"
(unqualified) instead?
No.
If you expect two child elements <a> and <b>, will you accept a <c> in
between? What if you have a <d> before the <a> but the mandatory element
<b> is missing altogether? Will you accept and know how to handle this
situation?
Yes. Yes/Depends.
Will you accept a namespace name "abcde" when a schema specifies the
namespace name "abcdef", or "abcdef/", or "ABCDE"?
No.
Are you saying that it has become a common idioma in application development
to expect and accept one or more of the above? I cannot believe you really
mean that.
I do agree that you may want to tolerate an addition to an element (say, an
extra child element, usually at the end of the "expected" content, or an
extra attribute). So what? ASN.1 supports this **formally** in the type
definitions. It has done so for many years. There is even a clause that
you can place at the beginning of an ASN.1 module and means that one must
expect additions anywhere.
I will have to read to see how that works with typical PER-based code.
I didn't think that typical implementations were that flexible.
This is a direct expansion of the IETF
meta-rule that states a similar principle. Furthermore, when
accepting
loosely and re-emitting an existing document/object, you attempt to
preserve anything originally present, even if you didn't
expect it. For
instance, an 'object', i.e. a complex data type, may have grown a new
field. You should not die when encountering this field and
if you are
modifying and exporting that object, you should preserve the field.
Exactly. This is what the ASN.1 notion of extensibility was invented for.
I don't understand how this works in practice yet.
...
ASN.1 is, of course, a logical data/API definition syntax,
ASN.1 defines no API whatsoever, nor do ASN.1 modules define APIs. ASN.1
modules define **data types**.
<Sigh> Make that "ASN.1 + xER + existing implementations".
Message format + semantic sugar = API or Message format + protocol +
semantic sugar = API
Standard message format implies standard API
Standard API does not imply standard API.
Normally, but not always.
However:
1) I can see this being done very often with XML Schema as well.
2) Other interfaces to ASN.1, such as SAX2, are perfectly possible. From
each XML document that conforms to an ASN.1 schema, you can obviously
generate a stream of SAX2 events. You can decode the XML instance into a
"value" and re-encode the "value" in BER or PER, without the application
being aware. If an ASN.1 tool supports this, you can write an application
based on SAX2. The application will be mostly agnostic of which encoding
rules are in use, and you can even change the encoding rules dynamically at
runtime. The application will receive the **same** SAX2 events regardless
of the actual encoding rules being used, be they XER, PER, BER, etc.
Remember that one of the basic principles of ASN.1 is that applications
should not be affected by the on-the-wire representation. This is a great
separation of concerns!!!
That's a completely different kind of separation of concerns that
doesn't help with the one I mentioned.
...
Alessandro Triglia
OSS Nokalva
sdw
--
swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
|
