[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Guidance sought re: changes for annotations
Hi folks, I started making the changes to the CVA specification according to our last teleconference. I wanted to get some discussion regarding the changes before engaging them, because I'm not sure how to proceed. Version 0.2 allows mixed content in constructs like <ValueList> and adding the new <Annotation> with <AppInfo> and <Documentation> there makes sense. But if I add <Annotation> below the document element, does that remove the need for <Identification> and <Description>? My thought is that <Annotation> should not have any standardized content at all ... it should be purely for users to add their own augmentation. Here is what a sample instance looks like now: <ValueListConstraints xmlns... id="urn:x-illustration" name="code-list-rules"> <Title> Illustration of code list constraints - order-constraints.cva </Title> <Identification> $Id: order-constraints.cva,v 1.6 2007/11/21 02:23:18 G. Ken Holman Exp $ </Identification> <Description> This is an illustrative example of all of the features of specifying the context/value constraints that one can express for XML documents. The validation requirements for this contrived scenario are as follows: - the UN/CEFACT currency code list is restricted to be only Canadian and US dollars - the seller must be in the US - the buyer may be in either Canada or the US - the definition for Payment Means is extended to include both UBL definitions and additional definitions </Description> Each of the above has the same content model as <Annotation><Documentation> would, that is, mixed content with any foreign vocabulary (e.g. XHTML). So, I'm thinking that <Annotation> does not belong as a child for any of <Title>, <Identification> or <Description>. For symmetry, though, should I force <Documentation> as a child of Title as in: <Title> <Documentation> Illustration of code list constraints - order-constraints.cva </Documentation> </Title> <Identification> <Documentation> $Id: order-constraints.cva,v 1.6 2007/11/21 02:23:18 G. Ken Holman Exp $ </Documentation> </Identification> Instead, should the second one be expected to be application info? <Title> <Documentation> Illustration of code list constraints - order-constraints.cva </Documentation> </Title> <Identification> <AppInfo> $Id: order-constraints.cva,v 1.6 2007/11/21 02:23:18 G. Ken Holman Exp $ </AppInfo> </Identification> My gut feel is "no", just leave those three as they are currently defined. The XHTML stylesheet expects to find content in the above constructs. If a user *also* adds <Annotation><Documentation> with XHTML at a child of <ValueListConstraints>, then where would that documentation "fit" with the other documentation? Therefore, should I only allow <Annotation><AppInfo> for annotating the document element? Should I give up on <Annotation> entirely for the document element? For the rest of the document model, I think I'm okay just adding <Annotation> with both <AppInfo> and <Documentation>. When producing the XHTML rendering of the CVA file I would mix the anticipated XHTML of the above <Title>, <Identification> and <Description> elements. Last question, as I realized I've not been looking closely at the genericode specification: XSD <annotation> has <documentation> and <appinfo> children, while genericode's <Annotation> has <Description> and <AppInfo> children. Should I go with <Documentation> or <Description>? Below is what a CVA file would look like using <Annotation> to add documentation to the non-documentary constructs. Does anything jump out at you as incorrect or unexpected? If I don't hear anything from anyone, I'll modify the document model accordingly to support what is below. Thanks! . . . . . . . . . . . Ken <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="Crane-assoc2html.xsl"?> <ValueListConstraints xmlns="http://docs.oasis-open.org/codelist/ns/ContextValueAssociation/cd-1.0/" xmlns:cbc="urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cac="urn:oasis:names:draft:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:x="http://www.w3.org/TR/REC-html40" xmlns:sch="http://purl.oclc.org/dsdl/schematron" id="urn:x-illustration" name="code-list-rules"> <Title> Illustration of code list constraints - <x:samp>order-constraints.cva</x:samp> </Title> <Identification> <x:pre> $Id: order-constraints-doc.cva,v 1.7 2007/12/26 23:29:53 G. Ken Holman Exp $ </x:pre> </Identification> <Description> <x:p> This is an illustrative example of all of the features of specifying the context/value constraints that one can express for XML documents. </x:p> <x:p> The validation requirements for this contrived scenario are as follows: <x:ul> <x:li>the UN/CEFACT currency code list is restricted to be only Canadian and US dollars:</x:li> <x:li>the seller must be in the US</x:li> <x:li>the buyer may be in either Canada or the US</x:li> <x:li>the definition for Payment Means is extended to include both UBL definitions and additional definitions</x:li> </x:ul> </x:p> </Description> <!--list all of the genericode expressions of agreed-upon code list value enumerations--> <ValueLists> <ValueList xml:id="currency" uri="CAUS_CurrencyCode.gc"> <Annotation> <Description> <x:p>Restricted to only Canadian and US dollars.</x:p> </Description> </Annotation> <MetaData> <ShortName>CurrencyCode</ShortName> <LongName>Currency</LongName> <LongName Identifier='listID'>ISO 4217 Alpha</LongName> <Version>2001</Version> <CanonicalUri>urn:un:unece:uncefact:codelist:specification:54217</CanonicalUri> <CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:54217:2001</CanonicalVersionUri> <Agency> <LongName>United Nations Economic Commission for Europe</LongName> <Identifier>6</Identifier> </Agency> </MetaData> </ValueList> <ValueList xml:id="states" uri="US_CountrySubentityCode.gc"> <Annotation> <Description> <x:p>List of US states.</x:p> </Description> </Annotation> </ValueList> <ValueList xml:id="provinces" uri="CA_CountrySubentityCode.gc"> <Annotation> <Description> <x:p>List of Canadian provinces</x:p> </Description> </Annotation> </ValueList> <ValueList xml:id="tax-ids" uri="TaxIdentifier.gc" key="codeKey"> <Annotation> <Description> <x:p>List of tax type identifiers</x:p> </Description> </Annotation> </ValueList> <ValueList xml:id="payments" uri="UBL_PaymentMeansCode-2.0.gc"> <Annotation> <Description> <x:p> Copied from the UBL 2.0 suite: <x:a href="http://docs.oasis-open.org/ubl/cs-UBL-2.0/"> <x:samp>http://docs.oasis-open.org/ubl/cs-UBL-2.0/</x:samp> </x:a> </x:p> </Description> </Annotation> </ValueList> <ValueList xml:id="additional_payments" uri="Additional_PaymentMeansCode.gc"> <Annotation> <Description> <x:p>An extra set of possible payment means.</x:p> </Description> </Annotation> </ValueList> </ValueLists> <!--list all of the contexts in which the value enumerations are used; where two or more contexts might match a given node in the input, list them here in order of most-important to least important match--> <Contexts> <Context item="@currencyID" values="currency"> <Annotation> <Description> <x:p>All currencies are restricted to only Canadian and US dollars.</x:p> </Description> </Annotation> </Context> <Context item="cbc:CountrySubentityCode" context="cac:BuyerCustomerParty" values="provinces states"> <Annotation> <Description> <x:p>The buyer can be in either Canada or the US.</x:p> </Description> </Annotation> <Message>Invalid province or state '<sch:value-of select="."/>' for buyer "<sch:value-of select="ancestor::cac:BuyerCustomerParty/cac:Party/cac:PartyName/cbc:Name"/>"</Message> </Context> <Context item="cbc:CountrySubentityCode" context="cac:SellerSupplierParty" values="states"> <Annotation> <Description> <x:p>The seller can only be in the US.</x:p> </Description> </Annotation> </Context> <Context item="cbc:ID" xpath="cac:TaxCategory/cbc:ID" values="tax-ids"> <Annotation> <Description> <x:p>Limit the recognized tax identifiers</x:p> </Description> </Annotation> </Context> <Context item="cbc:PaymentMeansCode" values="payments additional_payments"> <Annotation> <Description> <x:p>The payments can be by either standard or supplemental means.</x:p> </Description> </Annotation> </Context> </Contexts> </ValueListConstraints> -- Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008 World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]