[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: [ciq] Re: CIQ Specifications & XLink
Comments from Max: There is really no alternative. OK, lets invent our own linking/referencing standard, but it's not gonna make life any easier. Personally, I don't see any problem with xLink. All we really need to do is to make xLink optional and remove the xLink schema. Cheers, Max > > On 8/15/06, Colin.Wallis@ssc.govt.nz <Colin.Wallis@ssc.govt.nz> wrote: >> >> OK, so having agreed the approach, the two outstanding issues are >> deciding >> what additional/alternative implementation guidance on referencing we can >> give and who has the knowledge of those technologies to write it. (I am >> assuming here that we will alter the CIQ/xLink guidance when we have >> confirmation from XBRL that they agree). >> >> From the discussion so far, it would seem that the "WSDL to registry" is >> potentially an acceptable way forward. I don't know what Max's >> knowledge of >> Web Services is, nor others in the group. >> >> David, would it be possible for you to draft something for us to work >> from, >> following the style Max laid out in the xLink doc? >> >> We should try to engage the rest of the TC in agreeing this first >> though... >> >> Cheers >> >> Colin >> >> >> >> ________________________________ >> >> From: David RR Webber (XML) [mailto:david@drrw.info] >> Sent: Tuesday, 15 August 2006 2:36 a.m. >> To: WALLIS, Colin >> >> Cc: max.voskob@paradise.net.nz; kumar.sydney@gmail.com >> Subject: RE: [ciq] Re: CIQ Specifications & XLink >> >> From: David RR Webber (XML) [mailto:david@drrw.info] >> Sent: Tuesday, 15 August 2006 2:36 a.m. >> To: WALLIS, Colin >> >> Cc: max.voskob@paradise.net.nz; kumar.sydney@gmail.com >> Subject: RE: [ciq] Re: CIQ Specifications & XLink >> >> >> Colin, >> >> Agreed. We're just following this same recipe for the CPPA v3 and >> also the >> BPSS v2.0.3 - e.g. we provide the formal specification document that is >> normative and voted on - but then we supplement that with implementation >> guides / templates / best practices documents to align these operational >> aspects. The intent being that if sufficient buy-in occurs to certain >> methods - then eventually those can be formally inlined into the main >> spec' >> - but otherwise you avoid being too perscriptive - but again - still >> providing formal means to drive alignment and work on methods. >> >> Therefore - we could envision here having CIQ 3.0 document - but then >> provide a couple of implementation guides - e.g. XBRL and UBL. (I'm just >> experimenting with <xinclude> on the CPPA this week - so I'll provide >> feedback on that approach). >> >> BTW - this also makes finalizing the spec' document much easier - as >> you can >> take out those gnarly XML examples - et al - which seem to need constant >> tweaking and tuning - and if they are in the main document - its >> procedural >> re-voting and editing required - whereas if they are separate - then the >> main document merely needs to reference to them. >> >> The new docs.oasis-open.org/ciq is ideal for this - provides a static >> reference location to put these. >> >> Thanks, DW >> >> >> -------- Original Message -------- >> Subject: RE: [ciq] Re: CIQ Specifications & XLink >> From: Colin.Wallis@ssc.govt.nz >> Date: Sun, August 13, 2006 10:35 pm >> To: david@drrw.info >> Cc: max.voskob@paradise.net.nz, kumar.sydney@gmail.com >> >> << Anyway you slice the de rigour these days is web service / REST - not >> Xlink. That's why there's been no momentum behind Xlink implementation. >> Therefore - I'm seeing if people really do want to share a central >> addressing service - they will not use Xlink to do it - that's just >> too wild >> wild web. >> >> Yes, accepted (at least for WS - maybe still too early to call for >> REST) and >> it shows in the lack of tool support for xLink. >> >> << Also - its kinda an OASIS thing - to supply the basics in terms of >> the >> specification - but leave the implementation details to the specific >> need. >> Including Xlink kinda breaks that pattern...? >> >> And does this make OASIS better for its members I ask? (One of the main >> reasons for Liberty's continued existence is that OASIS delivers (for >> example) the SAML specs and leaves the implementation for others to sort >> out..like shopping..I'll go to Bakers for bread, the butchers for meat >> ..or >> I'll go to the supermarket and get it at one location) >> >> It's a fine line between offering too much prescription and not >> enough. If >> you offer no implementation guidance (and I'm meaning implementation of a >> particular deployment profile that has been constrained by the exchanging >> parties from the specification already) you leave the door wide open - >> maybe >> making it too hard for some people to take up the standard. On the other >> hand you don't want to constrain the implementation to the point that >> there >> is only one way... which is we try and base our OASIS outputs on use >> cases >> right?.. >> >> If we did go the WS route we would need to offer a guidance doc >> similar to >> the xLink doc we have now (but you've already sketched an example so >> that's >> a start!:-) >> >> Cheers >> Colin >> >> -------- Original Message -------- >> Subject: RE: [ciq] Re: CIQ Specifications & XLink >> From: Colin.Wallis@ssc.govt.nz >> Date: Sun, August 13, 2006 7:40 pm >> To: david@drrw.info, kumar.sydney@gmail.com >> Cc: ciq@lists.oasis-open.org, max.voskob@paradise.net.nz >> >> Thanks David >> >> While I see how the ebXML/web service approach might work and could >> be an >> alternative way to specify how to reference content in another >> location, I >> don't fully agree with your assertion that it is highly unlikely that no >> Customer info would be publicly accessible. >> >> I'm looking forward to Max's comments on this. But from memory, one of >> the >> drivers for this xLink - type referencing was, say, to access a unique ID >> for a property..say a Postal Address File - like service. >> >> Cheers >> >> Colin >> >> ________________________________ >> From: David RR Webber (XML) [mailto:david@drrw.info] >> Sent: Saturday, 12 August 2006 1:10 a.m. >> To: Ram Kumar >> Cc: WALLIS, Colin; ciq@lists.oasis-open.org; max.voskob@paradise.net.nz >> Subject: RE: [ciq] Re: CIQ Specifications & XLink >> >> >> Ram, >> >> OK got it. >> >> First up this seems highly unlikely usage! E.g. Essentially what this >> "Party" mechanism is doing is nothing more than CustomerID = "12345" in >> terms of information lookup! >> >> So I could send you: >> >> <c:Customers> >> <xpil:Party partyDetail-ID="12345"/> >> </c:Customers> >> >> and just let me use that "label" to retrieve the matching customer >> information. >> >> Also - it's highly unlikely folks are going to put customer info' out >> there >> via a URL reference - even if it is a secure URL... and share it across a >> community! >> >> Of course the "nice" thing about the Xlink is that the returned XML just >> gets inlined at that point. >> >> Reality however is that typical B2B practice is to just have a rule that >> makes the party details elements mandatory in the XML if the >> partyDetail-ID >> attribute is omitted or is empty. That a bit tricky to do with XSD - but >> easy to simply state in the specification, and then tools like CAM can be >> used to validate the content structure of actual transactions. >> >> Also - people are pretty comfortable / familiar with that normalized data >> approach. >> >> I'd really question if the XBRL folks would really use the XLink >> approach - >> even given their tools support it. >> >> Right now they use Xlink to achieve essentially spreadsheet cell type >> lookups for reporting purposes - so cell A10: contains a value - and that >> value type is referenced via an Xlink - etc - because XBRL is all >> about how >> you pass dynamically constructed financial accounting information via XML >> structure. >> >> There's a huge difference between exposing anonymous account codes for >> reporting via URLs across a community - compared to exposing actual party >> information! >> >> So - I'd say - use the label mechanism - and if people want more - >> then I'd >> suggest an ebXML registry lookup via a web service call instead of the >> Xlink. Because that can be secured. In CAM templates - we have the >> registry mechanism - where you declare the registry linkage and access. >> >> Then in the XML you can state the access path - so you'd do this: >> >> <c:Customers> >> <xpil:Party partyDetail-ID="12345" accessID="myRegistryWSDL01"/> >> </c:Customers> >> >> This approach would allow you to support Xlink via the backdoor if people >> really really wanted to do that - because they'd define the access >> method as >> Xlink. >> >> E.g. myRegistryWSDL01 - would resolve to an Xlink access method, >> instead of >> WSDL to registry. >> >> Here's how you do that kinda dynamic linkage to the information source: >> >> >> <Addressing> >> >> <registry accessID="SGIR" access="registry.sgir.org:1023" >> method="URL" >> >> description="Sporting Goods Industry Registry"/> >> >> <registry accessID="SGIRWSDL" access="registry.sgir.org:1025" >> method="WSDL" >> >> description="Sporting Goods Industry Registry"/> >> >> <registry accessID="UN" access="registry.un.org:9090" method="ebXML" >> >> description="United Nations EDIFACT Registry"/> >> >> <registry accessID="UPS" access="registry.ups.com:7001" method="URL" >> >> description="United Parcels Service Registry"/> >> >> <registry accessID="USPS" access="registry.usps.gov:8080" >> method="URL" >> >> description="United States Postal Service Registry"/> >> >> <registry access="Local" access="rdbms.mybusiness.com:4040" >> method="SQL" >> >> description="Local Product Database stored procedures"/> >> >> </Addressing> >> >> Cheers, DW >> >> -------- Original Message -------- >> Subject: Re: [ciq] Re: CIQ Specifications & XLink >> From: "Ram Kumar" <kumar.sydney@gmail.com> >> Date: Fri, August 11, 2006 8:00 am >> To: "David RR Webber (XML)" <david@drrw.info> >> Cc: Colin.Wallis@ssc.govt.nz, ciq@lists.oasis-open.org, >> max.voskob@paradise.net.nz >> >> David and Colin, >> >> The enclosed document should give you the idea of what we wanted to >> achieve with xLink. If we can use some other atlernative solution to >> this, >> it will be great. I would like to keep xlink also as an option for >> linking >> resources as XBRL wants interoperability with CIQ. >> >> Any suggestions will be great. >> >> Regards, >> >> Ram >> >> >> On 8/11/06, David RR Webber (XML) <david@drrw.info> wrote: >> > >> > Colin, >> > >> > I'm a great believer in KISS, and especially the power of simple >> plain-old >> > XML! >> > >> > I think we need to understand better what Ram was seeing using the >> XLink >> > does - in terms of functionality / goals. >> > >> > Once we understand that - then I'm sure we can optimize on ways to >> achieve >> > that - without getting too exotic hopefully! >> > >> > Thanks, DW >> > >> > >> > >> > -------- Original Message -------- >> > Subject: RE: [ciq] Re: CIQ Specifications & XLink >> > From: Colin.Wallis@ssc.govt.nz >> > Date: Thu, August 10, 2006 8:17 pm >> > To: ram.kumar@oasis-open.org, david@drrw.info >> > Cc: kumar.sydney@gmail.com, ciq@lists.oasis-open.org, >> > max.voskob@paradise.net.nz >> > >> > It's time to resurrect that email from Tony Coates that offers some >> other >> > suggestions. It would seem that we are going to offer some >> alternatives to >> > the optional xLnk (though I was not aware it was optional ..the spec >> gives >> > it stronger emphasis. Alternatives will need to have a good level >> of tool >> > support - goes without saying really.. >> > >> > This is what Tony said, and might give us a steer as to alternatives we >> > could offer: >> > >> > <<In terms of the W3C, I think XLink is all but a dead spec. XBRL >> is the >> > only user of any importance. The W3C's effort these days are >> directed at >> > RDF & OWL. Norman Walsh from Sun (& the W3C TAG) occasionally write >> > thoughts about things that could be done with XLink, but I don't' think >> > there is a lot of enthusiasm. >> > >> > So, in terms of namespace policy, my personal suggestion would be >> that you >> > try do something compatible with RDF usage, and even think about >> moving to >> > RDF if at all possible. Now, I'm not an RDF expert. If you need >> contacts, >> > I could ask Norm Walsh who the best contact is. >> > >> > Cheers, Tony. >> > -- >> > Anthony B. Coates >> > Senior Partner >> > Miley Watts LLP >> > Experts In Data >> > +44 (79) 0543 9026 >> > Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312, >> UN/CEFACT >> > TMG, MDDL, FpML, UBL.>> >> > >> > >> > -----Original Message----- >> > From: Ram Kumar [mailto:ram.kumar@oasis-open.org] >> > Sent: Friday, 11 August 2006 7:43 a.m. >> > To: David RR Webber (XML) >> > Cc: Ram Kumar; ciq@lists.oasis-open.org; Max Voskob >> > Subject: Re: [ciq] Re: CIQ Specifications & XLink >> > >> > David, >> > The reason why xlink is now important for CIQ is because of XBRL's >> > requirement to interoperate with CIQ due to some end user requiements. >> > We can have xlink optionally, and >> > also another simple approach in CIQ that can be used instead of xlink. >> > What do >> > you think? If this sounds fine, what is this other simple approach >> to link >> > resources? >> > Any suggestions? >> > >> > Ram >> > >> > David RR Webber (XML) wrote: >> > > Ram, >> > > >> > > I concur with Michael on this one. >> > > >> > > The only folks using Xlink that I know are the XBRL - and its >> almost a >> > > deliberate choice there - since then you have to use a XBRL tool that >> > > has Xlink support in it - creates a closed marketplace. >> > > >> > > I suggest that we look for other means here. >> > > >> > > The issue with general Xlink support for regular parsers - eg Xerxes >> > > - is quite literally - how long is a piece of string? With an XML >> > > document - its finite - and hence has a local memory model. When you >> > > do Xlinks - you do not know what you are Xlinking (in the general >> > > case). Obviously in the case of XBRL its a finite closed world - so >> > > that works OK. >> > > >> > > Perhaps we can use includes or imports - or use simple http URL links >> > > inside comments - to provide the logical linkage you are after? Also >> > > - we now have the static area: >> > > >> > > docs.oasis-open.org/ciq >> > > >> > > available to us - so we can reference to content there too - if you >> > > need to associate? >> > > >> > > DW >> > > >> > > >> > > -------- Original Message -------- >> > > Subject: [ciq] Re: CIQ Specifications & XLink >> > > From: "Ram Kumar" <kumar.sydney@gmail.com> >> > > Date: Thu, August 10, 2006 10:22 am >> > > To: michael.blaim@kremsresearch.at >> > > Cc: ciq@lists.oasis-open.org, "Max Voskob" >> > > <max.voskob@paradise.net.nz> >> > > >> > > Dear Michael, >> > > >> > > The reason we want to use XLink is that it simplifies providing >> > > links between multiple resources (e.g parties) and relationships >> > > between the resources that might exist in multiple documents. >> > > >> > > Regards, >> > > >> > > Ram >> > > >> > > On 8/11/06, michael.blaim@kremsresearch.at >> > > <michael.blaim@kremsresearch.at> wrote: >> > > > >> > > > Dear Mr Kumar, >> > > > >> > > > We are currently working on an XML specification for customer >> > > (party) >> > > > information for travel and tourism with special focus on data >> > > protection and >> > > > security. We use xNL, xAL (v3.0) and xCRL (v2.0, but we are >> > > looking forward >> > > > to v3.0). These specifications really meet our requirements >> > > (flexibility, >> > > > scalability, granularity etc) so far. The one thing we are not >> > > sure of is >> > > > the XLink references. Although XLink is ideal for XML >> references >> > > in theory >> > > > we can't find a way to put it into practice (with processors, >> > > parsers etc). >> > > > So what is the reason for CIQ TC to use XLink? >> > > > >> > > > Best regards >> > > > Michael Blaim >> > > > >> > > > Research Fellow >> > > > Tourisms Research Center Krems >> > > > Hofrat Erben Str 4 >> > > > 3500 Krems >> > > > Austria >> > > > phone: +43 2732 72177 25 >> > > > fax: +43 2732 72177 21 >> > > > mail: michael.blaim@kremsresearch.at >> > > > web: http://www.kremsresearch.at >> > > > >> > > > anet - austrian network for e-tourism >> > > > http://www.anet-network.at >> > > > >> > > > >> > > > >> > > >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]