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:
If you have the following type definition:

PersonInformation ::= SEQUENCE {
	name UTF8String,
	age-elem [NAME AS "age"] INTEGER OPTIONAL,
	address UTF8String,

the ellipsis ("...") indicates a position in the sequence (usually but not
necessarily at the end) where an "addition" may occur.

A writer may add stuff after the "address" field.  PER wraps the stuff and
adds a length prefix right before it.  A reader will be able to either
decode the stuff (if he thinks it understands it) or skip it.  If a reader
decides to relay the message, it can re-include the wrapped stuff in the
message, whether or not it understands the stuff.

Without the ellipsis, it is forbidden to add anything after the address.
With the ellipsis, the wrapping mechanism ensures that any addition will be
recognized as such, whether or not it is understood.
That's cool, but I still don't understand how fields are identified in a way that is usable and supportable in other than tightly coupled environments.  (Where tightly coupled includes standards like H.323, SS7, cell networks, etc.)

If there exists an application as above and it is receiving messages from multiple parties, say many different schools submitting graduation records.  What if one school adds a height field and another adds a languages field?  This interface can see those fields without confusion and pass them on to another tier?  Is there a way for this tier to interpretively process those fields in a coherent way?

I think that you've shown that a receiver can handle extensions from the one changer of formats which helps with schema evolution to some degree, but it still doesn't seem like loose coupling.
<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.
Sorry, I still don't get it.  An API is not the same thing as a data type.
Why do you think they are the same thing?

A "remote procedure call" is the transfer of a message with associated semantics that map that message to a method or method stub and return the results with an associated semantic.  A "protocol" is the transfer of messages with a certain semantic where the processer of messages may eventually call a method.  Although distinct models, they aren't necessarily that far apart semantically.  Even a local method invocation can be represented as a pair of messages.  Some paradigms extend this: SQL servers generally receive a single request and may respond with any number of responses.  SOA methods like message passing/oriented point to point and publish/subscribe have much more rich possible communication patterns.

To be clear, you can have data types that are just data types such as "Person" and data types that represent an RPC/message of some type such as: NewPerson{ Person np }, NewPersonReponse{ ID newid, Success ok }.

It's better to define the message traffic, ok to define the protocol also, and marginally useful to describe the 2GL API.

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