[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Validation vs performance - was Re: Fasttext out

sax vs sax2
Alessandro Triglia wrote:
-----Original Message-----
From: Stephen D. Williams [mailto:sdw@l...]
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@h... http://www.hpti.com Per: sdw@l... http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
fn:Stephen Williams


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.