RE: [ciq] Re: CIQ Specifications & XLink

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

ciq message