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

Re: Validation vs performance - was Re: Fasttext out


semantic sugar
Alessandro Triglia wrote:
...
If you have the following type definition:

--------------------------------------------------
PersonInformation ::= SEQUENCE {
	name UTF8String,
	age [ATTRIBUTE] INTEGER OPTIONAL,
	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?

Alessandro
  
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.

sdw
-- 
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

begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@l...
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@l...
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard


PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.