Hi all
Here are some views informed by some conversations with a couple of experts, but probably distorted by my position of relative ignorance, so correct me if I am wrong, but:
- CCTS (and therefore perhaps UBL?!) discourage use of Key/KeyRef. The NDR defines direct transformation from CCTS data models into XSD expressions in a one for one manner. I believe this is because use of referencing mechanisms breaks the semantic relationships. Use of Key/KeyRef allows you to guarantee ‘Referential Integrity’, but it doesn’t say anything about the semantics. It is a syntactic, not a semantic relationship. In a nutshell, a reference to a thing is not the thing itself.
>>> I agree. Key/KeyRef was added to schema by the SQL database community to support primary key/foreign key concepts. My sense here is that setAssociation() may offer the benefits without the drawbacks - and especially because this does not burden the XML instance itself.
<<<
- You could mimic all referential constraints as business rule expressions for the value validation, rather than trying to shoehorn such constraints into the structural schemas. “Where this value references another then (a) the referenced value must exist and (b) the referenced value must follow these constraints”. Again, this does not say anything about the semantics of the relationship.
>>> Agreed - this is really a shorthand notion for equivalent longhand coding using XPath expressions currently. The big advantage being that parsing software can recognize setAssociation() explicitly whereas the purpose of the equivalent XPath expressions is harder to discern consistently - without adding your own annotation type cues. <<<
- But, cross referencing between components is surely a ‘good thing’ since it reduces duplication of data, and also the need for deeply nested hierarchies. Instead of the same data appearing in two locations, you can use references to refer to one copy of the data.
>>> Excellent point - which I'd missed in my original thoughts. Although of course IDREF is supposed to cover this need in an XML instance - that introduces a foreign key value - whereas using say the actual CustomerNumber is the direct data item and familiar business data approach.
<<<
As I say, I might be wrong on all counts. Just trying to understand. I must say that from a pragmatic point of view, it would be nice to be able to express such relationships, but from a strict ‘semantic interoperability’ point of view there may be issues?
>>> What I'm hoping is the reverse actually! Right now people may often have these relationships implicitly in their data exchanges - but without ways to formally call this out in rule definitions - there is no way to communicate that downstream. Since the setAssociation() does not have any rigid validation role - its purely informational - implementors can choose to enforce or relax handling around those as needed.
<<<
Regards
Richard Furze, B.A., M.Sc
Technical Project Manager &
Technical Architect
OSCRE – Global Standards for Real Estate
+44 191 230 8094 Office
+44 7884 077268 Mobile
Email: richard.furze@oscre.org
Office address: Churchill House 12 Mosley Street, Newcastle-upon-Tyne NE1 1DE
OSCRE is the only global e-commerce standards body for the real estate industry.
OSCRE provides a forum and proven processes for the collaborative development and adoption of free and publicly available open interface specifications. OSCRE’s principle mission is to promote standards and standards adoption among all stakeholders, to the mutual benefit of all participants, and enable the real estate industry to function more efficiently in the digital economy.
OSCRE is the trading name of Property Information Systems Common Exchange Standard Limited, a non-profit company registered in England & Wales and limited by guarantee.
Registered number: 3582333. Registered office: Euro House, 1394 High Road, London N20 9YZ. VAT number: 711128970.
The contents of this email and any file attachments are confidential to the intended recipient and may not be disclosed or used or copied in any way by anyone other than the intended recipient unless such usage is authorised. If you have received this email in error please notify us either by return e-mail or via the numbers above. Any views or opinions expressed are solely those of the author. Please note that we do not accept any responsibility for software viruses or the content, accuracy or completeness of this email or its file attachments as it has been delivered over a public network. It is the recipients responsibility to scan or otherwise check this email and any file attachments.
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 16 April 2010 22:25
To: CAM OASIS TC
Subject: [cam] New feature in CAM - setAssociation() ?
I think I've encountered a good new potential feature.
The genesis for this is within data - there are primary and foreign keys - and these are not explicitly called out anywhere in the XML itself - they are just tacitly in there - i.e. customer has customer_number, orders with customer_number and so on.
The idea here is to provide an automated way of linking these associations - a shorthand method. Also - by making them rules - good things happen as side effects - I can filter on those - show a "Key" symbol in the editor and so on.
This then also allows CAM templates to show semantic linkage - across and between parts in an XML exchange - using a simple and intuitive rule method e.g. setAssociation(Xpath)
On any element in a CAM template - essentially you are adding a rule hint the value in the Xpath tells you what field you are pointing to - so can be anything you want in the XML structure - customerId, SSN, @id, whatever - while the specific value in that thing is then the cross-reference value.
This type of rule is different from the strict validation rules we've had up until now as its sole purpose is to show semantic relationships. It is more akin to the KeyRef mechanisms in XSD Schema - and the RDF linked data ideas.
Your thoughts appreciated.