mlhim-owners team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

Hi Tim,

It did help a lot. Thank you for the referral to the XML documentation.
It is understandable even for physicians with a very superficial
exposure to programming, such as me. We just need to take a breath and
read it slowly. ;-)

I am convinced that those ideas for Slots are operational as far as the
XML technologies go; my only remaining concern is related to the RM and
the large-scale implementation (one day it will happen).

If Slot is a class and it inherits directly from Locatable, does that
mean that any MLHIM 2 RM class CCD might be put inside a Slot?

If yes, don't you think that that might be dangerous as far as knowledge
modeling goes, or are we using here the principle of transferring the
responsability to knowledge modelers (primarily) and app developers
(secondarily)?

Thnak you,

Luciana.


Em 19/09/2011 00:21, Timothy Cook escreveu:
> Hi Luciana and All,
> 
> Just too be sure everyone is on the same page.  I am working with the
> CDD 2.3.0 found here:
> http://bazaar.launchpad.net/~cdd-dev/cdd/trunk/view/head:/CDD-2.3.0.xmt
> 
> Use BZR to get a copy if you need.  bzr branch lp:cdd
> I think it is easier for people to see the model this way even though
> in reality the mindmap file is a reproduction of the EMF model.
> 
> At this point I am only going to address the concerns about Slots.  I
> will wait for other comments before getting into other issues.
> 
> I'll call this:  "Slots and the Magic of Namespaces"
> I have attached a small image of the Slots class for reference.  Using
> the actual mindmap is preferred though.
> 
> Notice that Slots has two attributes other than the ones inherited
> from Locatable. the 'ccd' attribute is for the actual selected CCD
> from the list of 'allowed_ccds'.  The descriptions here need to be
> expanded to say Fully Qualified Domain Name (FQDN) it is not meant to
> be just the CCD IDs.  This is because what will happen is that you can
> have CCDs from many different servers.  Even though CCD IDs are UUIDs
> I still believe it is beneficial to carry the FQDN in case some people
> do not register their CCD in the HKCR.net  network.
> 
> When CCD instance data is created then the FQDN becomes the namespace
> for whatever data is collected in the referenced CCD.
> 
> There is a short explanation of namespaces here:
> http://www.w3schools.com/xml/xml_namespaces.asp
> 
> Further info is here:
> http://www.w3.org/TR/REC-xml-names/#sec-namespaces
> 
> So in the XML it might look like this (simplified):
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <ccd
>   xmlns:ccd1="http://www.hkcr.net/ccd/3hios3rf8l8r1a13pccevqevc9.xsd";
>   xmlns:ccd2="http://www.hkcr.net/ccd/3o8f564em78rbuf1pn15m3odf4.xsd"/>
> 
>   <ccd1:attr_x>Some data</ccd1:attr_x>
>   <ccd2:attr_x>Some different data.</ccd2:attr_x>
> 
> ... lots more meta-data and instance data ...
> 
> </ccd>
> 
> So through labelling the instance attributes with ccd1 or ccd2 then
> the tooling can tell which CCD (XML schema)  that data is required to
> conform to.  Therefore if you had a CCD with 10 Slots in it each set
> of attributes from each CCD would have a different label.  This is how
> XML tools work.  Of course you don't have to use ccd1 and ccd2.  You
> could use aaa and xxx as labels or you could use the whole CCD ID. But
> the network people would shoot you for the extra payload.  :->
> 
> I hope this helps a bit.
> 
> Regards,
> Tim
> 

-- 
Esta mensagem foi verificada pelo sistema de antiv�s e
 acredita-se estar livre de perigo.