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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] Standards approval process


There is no representation of storage within the document for two reasons.

1. Until we understand and agree WHAT the serialization is, it is 
pointless to define the storage.  It is like saying go out and build a 
road to City X, but we won't tell you where city X is.  It is a 
dependency.  Until you understand and know what the thing is, you should 
not try to map it to another thing.  Logic does not get much more 
fundamental than that.

2. IMO - we should not tell people HOW to store something, we should 
only care about the thing we get back when we ask for it.  We do not 
tell people that the RIM must be implemented in a relational database?  
That is because those who implement it should have control over that 
detail.  They can use text flat files if they want (very bad idea BTW).

I feel like a broken record since 2000.

My $0.02 worth.

Duane

Chiusano Joseph wrote:

><Quote>
>joseph is correct
></Quote>
>
>I shouldn't different with someone who says I'm correct, but in this
>case I was not stating preference either way (serialization or storage).
>I actually do have a preference for one, but I'll never tell which ;) I
>was just clarifying why there was no representation of storage within
>the document. Thanks anyway Duane!
>
>Joe
>
>Joseph Chiusano
>Booz Allen Hamilton
>Strategy and Technology Consultants to the World
> 
>
>  
>
>>-----Original Message-----
>>From: Duane Nickull [mailto:dnickull@adobe.com] 
>>Sent: Monday, January 17, 2005 11:53 AM
>>To: BEDINI Ivan RD-BIZZ-CAE
>>Cc: Chiusano Joseph; regrep@lists.oasis-open.org; Farrukh 
>>Najmi; Breininger, Kathryn R; David Webber (XML)
>>Subject: Re: [regrep] Standards approval process
>>
>>Ivan:
>>
>>The document is not complete and there are problems that 
>>UN/CEFACT has clearly not addressed yet.  For that reason, I 
>>am stopping work on this document.
>>
>>joseph is correct  - the serialization is far more important 
>>than the storage.  Please get off this whole idea of how to 
>>map to the RIM until it is understood what the serialization 
>>will be.  There is a dependency on this and until this is 
>>solved, you and everyone else working on the storage are 
>>probably not spending your time well.
>>
>>Some partial answers inline:
>>
>>BEDINI Ivan RD-BIZZ-CAE wrote:
>>
>>    
>>
>>>how to represent an ABIE for example.
>>> 
>>>
>>>      
>>>
>>XML Schema can represent this.  There are things that XML 
>>Schema cannot do and those will be limitations.
>>
>>    
>>
>>>an ABIE normally is an aggregate of more simplest basic 
>>>      
>>>
>>components and 
>>    
>>
>>>less simplest associations to others aggregate objects.
>>> 
>>>
>>>      
>>>
>>Associations may be represented in the registry but in a 
>>serialization, they can be expressed again using XML Schema 
>>(or XMI perhaps).
>>
>>    
>>
>>>to define an ABIE you need to define its structure too and I can't 
>>>understand how we can define that in the property element of the 
>>>serialisation.
>>> 
>>>
>>>      
>>>
>>Again - XML schema and XMI are the best tools we have.
>>
>>    
>>
>>>there, all elements are only sequentially put in the XML 
>>>      
>>>
>>document and 
>>    
>>
>>>so doing we lose :
>>>- the structure of a CC
>>> 
>>>
>>>      
>>>
>>Not true.  It is still referencable via the UUID.
>>
>>    
>>
>>>- all associations between CCs
>>> 
>>>
>>>      
>>>
>>Not true - you can query the registry.
>>
>>    
>>
>>>- XML potentialities to automate structure and semantic 
>>>      
>>>
>>controls of the 
>>    
>>
>>>data submission.
>>> 
>>>
>>>      
>>>
>>We actually wrote such an engine to help build documents out 
>>of CC's with context declarations.  It is not a trivial thing to do.
>>
>>There is a lot of work that needs to be done.  
>>
>>Duane Nickull
>>
>>--
>>***********
>>Senior Standards Strategist - Adobe Systems, Inc. - 
>>http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - 
>>http://www.unece.org/cefact/ Chair - OASIS eb SOA TC - 
>>http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
>>***********
>>
>>    
>>
>
>  
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]