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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

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


Subject: RE: [ciq] CIQ Specifications and xLink


Colin,
 
IMHO - this is the tail wagging the dog.
 
Sure XBRL will love you - but noone else will - because they want to use just COTS tools - and most of them do not support Xlink.
 
My sense is that we can achieve this using registry based approach - which is an OASIS standard and for which community support open source tools exist.
 
It also make sense too for the XBRL community as a next step to adopt registry tools - like the healthcare community is doing - because then their accounting systems will be interoperable with healthcare delivery - which is a huge market for them.
 
We can re-use the work Max has done - to show how to do those exact same techniques using registry.  We may need to add an optional attribute to the CIQ to support this type of lookup - but that is much cleaner - since implementors can use a whole array of tools to do that - Perl, Ruby, Python, SQL, Java, web service, registry, etc, etc - we're not locking them into just Xlink...
 
Cheers, DW


-------- Original Message --------
Subject: [ciq] CIQ Specifications and  xLink
From: colin.wallis@ssc.govt.nz
Date: Thu, August 17, 2006 12:01 am
To: ciq@lists.oasis-open.org

<Comments from Max:
<There is really no alternative>.

Really? wow..

<OK, lets <invent our own <linking/referencing standard, but it's not <gonna make life any easier.

No, we don't want to invent one, we want to re-use an existing one that has good industry support, so we have an answer to emails like Michael Bain's email to Ram "...Although XLink is ideal for XML references in theory we can't find a way to put it into practice (with processors, parsers etc)".


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

OK, if Max can't see a problem and Michael can, it would be good if they can engage to clear it up and we can take that knowledge forward.

Max has taken a lot of time and effort to produce the xLink guidance doc so it would be crazy to waste it. Once it has the xBRL-proposed URI change in it, we are sweet, yes? At the very least xBRL will use it!

Then the only question remaining is, do we offer guidance on any other form of linking/referecing or not, and if so, what is it, and who can draft it?

Cheers
Colin


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