RE: [wsrp-wsia] Roles

We did take a look at these standards
(xNL and xAL), but decided to just align with the P3P structures for v1.
Re-examining the use of broader name and address standards (there are several)
was deferred until v2.

Rich Thompson

"Ram Kumar" <>

04/09/2003 11:45 PM
        

        To:
       Rich Thompson/Watson/IBM@IBMUS, "'Martin
Bryan'" <>

        cc:
       <>

        Subject:
       RE: [wsrp-wsia] Roles

Hi Rich

Just wondering whether WS-RP is implementing the address

standards of OASIS CIQ as part of its specifications?

Regards

Ram Kumar

Chair, OASIS CIQ TC

> -----Original Message-----

> From: Rex Brooks [mailto:]

> Sent: Wednesday, 27 November 2002 12:48 AM

> To: Rich Thompson; Martin Bryan

> Cc: ; 

> Subject: Re: [wsrp-wsia] Roles

> 

> 

> Hi Rich, Martin, Everyone,

> 

> In the Human Markup Language XML Primary Base Schema/Specification

> 1.0 our TC approved for public comment at the start of November, we

> declared the xAL 2.0 (extensible Address Language) and the xNL 2.0

> (extensible Name Language) schemata of the OASIS Customer Information

> Quality TC, and imported the HR-XML Consortium's personName_1.2 and

> postalAddress_1.2 schemata as well as XNSORG/OneName's XNS-1.0 specs

> for the purpose of making our specification interoperable  with
these 

> specifications, the imported namespaces are commented out for now

> because those organizations have urn/schemaLocation concerns under

> consideration, but which are scheduled for minor revisions in those

> areas shortly after the start of the year. It is likely that we will

> also import or declare XLIFF as well.

> 

> Is it possible to simply make role fields optional?

> 

> Ciao,

> Rex

> 

> At 7:51 AM -0500 11/26/02, Rich Thompson wrote:

> >I have had the uneasy feeling about roles for a while, but 

> rewriting those

> >sections finally caused me to focus on it enough to see the detailed

> >reasons why (you site some good examples). At this point I 

> think it is only

> >useful to that set of Consumer-Producer pairs that have a 

> coordinated set

> >of roles and since we won't be able to define tight 

> semantics it doesn't

> >belong in the spec.

> >

> >On the address side, the variations in address are a big 

> issue and WSRP is

> >not the right place to tackle it. We took guidance from the 

> P3P data model

> >in this area though we did need to provide some structure for
their

> >unstructured portions. I was hoping much of the variability 

> could go into

> >the field named street as this is an array of strings. In 

> addition, each of

> >the structures is individually extensible with the 

> expectation that some of

> >those extensions will come back for consideration as base 

> level fields in

> >v2. If there are other sources that would give a more 

> internationalized

> >view of this area, we certainly would appreciate a pointer ....

> >

> >

> >

> > 

> >                  
                     
                    

>                    
                     
          

> >                  
    "Martin 

> >Bryan"                
                     
                

>                    
   

> >                  
    <[email protected]        To:  
    Rich 

> >Thompson/Watson/IBM@IBMUS            
              

> >                  
    et.com> 

> >cc:                  
                     
                     
 

> >                  
                     
       Subject:  Re: 

> >[wsrp][wsia] Draft spec v0.85          
             

> >                  
    11/25/2002 

> >11:35                
                     
                 

>                    

> > 

> >AM                  
                     
                  

>                    
           

> > 

> >                  
                     
                    

>                    
                     
          

> > 

> >                  
                     
                    

>                    
                     
          

> >

> >

> >

> >

> >Rich

> >

> >>  Reflecting on this further, the whole schema of role

> mapping only really

> >>  works when there is a huge overlap in the roles supported

> at the Producer

> >>  and the Consumer. To me this is more and more smelling

> like something

> >that

> >>  belongs as an extension rather than an inherent part
of the spec.

> >

> >At last you are beginning to see the problem. Now consider 

> what happens if

> >the Producer is Finnish and the Consumer is Japanese and 

> both use their own

> >languages to define their services. Now we have a real 

> problem, which will

> >only be solved if you introduce a multilingual ontology of 

> mapped terms

> >into

> >the equation.

> >

> >The real problem, however, is how to do this dynamically, so 

> that we can

> >annotate recorded roles with "related names from other sources"
(e.g.

> >record

> >that someone has determined, by some off-line means, that A 

> relates to B).

> >

> >Incidentally your address info structure in section 10 has not
been

> >suitably

> >internationalized. You need techniques for defining 

> subsections of what you

> >call cities (e.g. Kensington, London) and for identifying 

> blocks (both at

> >street and house level) and subunits of buildings (flats or 

> suites). For

> >example, I have a friend in Roumania for whose address I 

> need to identify

> >the flat number, the staircase, the block on the road 

> (unless you call

> >Block

> >26 a name!) and the district of the town in addition to the 

> fields you

> >allow

> >me to define once only if I want to send him something. It 

> looks like I'm

> >going to have to define more extensions than you do base fields,
even

> >though

> >every different Consume and Producer will have to define his 

> own set of

> >extensions for most of these :-(

> >

> >Martin Bryan

> >The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU,
UK

> >Phone/Fax: +44 1452 714029  E-mail: 

> >

> >For further details about The SGML Centre visit 

http://www.sgml.u-net.com

>

>

>

>

>

>

>

>

>

>

>

>----------------------------------------------------------------

>To subscribe or unsubscribe from this elist use the subscription

>manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 

Rex Brooks

Starbourne Communications Design

1361-A Addison, Berkeley, CA 94702 *510-849-2309

http://www.starbourne.com *