OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Validation vs performance - was Re: [xml-dev] Fasttext out

[ Lists Home | Date Index | Thread Index ]

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"
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>
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?
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
Yes.  Yes/Depends.
Will you accept a namespace name "abcde" when a schema specifies the
namespace name "abcdef", or "abcdef/", or "ABCDE"?
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 
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.


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

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
fn:Stephen Williams


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS