Re: [clr-dev] Additional information about InstanceMetadataSets

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-10-07 22:10 -0500, ericdes wrote:
>I was far from understanding one could add an additional attribute 
>(such as the metadata attribute "isoyear" in your example) in a 
>document that makes use of genericodes

Sorry, Eric, but it is the *other* way around.  The vocabulary 
designers have *already* included the isoyear="" attribute in the XML 
vocabulary because they recognized the need for disambiguation.  CVA 
files are then written to exploit what is already there to be 
used.  If you specify brand new properties in the CVA file and try to 
use them in your XML your XML will violate the schema constraints if 
the schema is not originally designed to have these properties.

I've been delivering my code list presentation to audiences around 
the world trying to convince designers of vocabularies using code 
lists that they need to design in the disambiguation metadata properties.

>(Do CIQ, UBL allow this?)

UBL has many metadata attributes, both for code lists that are used 
in elements and code lists that are used in attributes.  The 
designers of "supplementary components" for core components in the 
UN/CEFACT modeling of business objects for trade documents had 
already specified this metadata.  I regret, however, they didn't go 
far enough in some cases.  It would be nice if there was even *more* 
metadata available.  But I can't go in and add properties that aren't 
already there, or the UBL instances won't validate against the UBL schemas.

The schemas of the UN/CEFACT data types with the metadata constructs 
are here (in particular look at CodeType and AmountType as examples 
of, respectively, the use of a code list in an element and the use of 
a code list in an attribute):

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/xsd/common/CCTS_CCT_SchemaModule-2.1.xsd

The CVA files I created to exploit these UN/CEFACT supplementary 
metadata constructs in the UBL vocabulary are here:

   http://docs.oasis-open.org/ubl/prd1-UBL-2.1/cva/

>just because a CVA contract (that specifies a set of medatada) is there.

Not "just because" ... the properties have to be designed in from the start.

>I was under that impression that a CVA file was used to specify 
>codelists and validation rules, I would never have thought it could 
>have gone so far as to allow injection of attributes (maybe of xml 
>elements too?) into the exchanged documents.

As above, they do not "allow" the injection of attributes.  They 
exploit the preexisting attributes that have been designed in by the 
vocabulary designers precisely for this purpose.

In fact I designed CVA files because the properties were sitting 
there and not yet being exploited.  During a 2005 UBL face-to-face 
meeting the problem requirement was eloquently expressed by our 
member Stephen Green and I articulated how XPath could be used to 
satisfy the requirement.  That led to my prototypes and the eventual 
polish of the CVA file that you see today.

>I'm still not sure what the consequences are (I mean as for the 
>applications I'm developing).

Hopefully the metadata attributes you need are already sitting there 
in the schema for your XML waiting for you to use.  No-one can simply 
add attributes to your XML that you aren't expecting.

When designing the XML the rule of thumb would be to create a home in 
your XML for each of the pieces of information found in the 
<Identification> elements of genericode.

I hope this helps.

. . . . . . . . . . . . . Ken

--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/c/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/c/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/c/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal