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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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

Subject: Re: [ubl-lcsc] [code:fixed-attribute-value] Straw-man 2 Code list proposal - candidate final

At 2003-09-11 02:34 +0800, Chin Chee-Kai wrote:
>2. For the file "UBL-CodeList-StatusCode-Private-Adjunct-strawman-2.xsd"
>the use of a "fixed" value attribute associated with the code type
>is a mechanism that would be copied or instantiated in all places
>where an element is defined to have that particular code list type.


>This, again, in my opinion, may not appear good because the fixed
>value attribute gets instantiated (where schema-validation is
>performed) all over the places where the code element itself
>is instantiated.


>Does that make sense?

For downstream processing, many processing languages (such as XSLT) do not 
give access to the schema expression, only to the elements, attributes and 
PSVI additions from schema validation.  The presence of the fixed attribute 
ensures that a processing application with schema validation will see the 
reference to the schema adjunct file associated with a coded value.  This 
gives the processing application the opportunity to access the schema 
adjunct file at run time.

>Following the marathon LC call last nite, perhaps another mechanism
>to store the metadata "myAdjunctFile.xml" is to use the newly
>defined <ccts:Instance>, and to create a new sub-child such as
><ccts:AdjunctFilename> (the local name is just a suggestion for
>lack of a better name).  As the adjunct file name is a
>schema-validation-time  constant and not used in instance-run-time,
>its instantiation in code elements would not be required, and
>storage in the annotation portion might seem good enough.

I understand that there is a conformance level by which a validating schema 
processor is allowed to maintain only the result of PSVI interpretation and 
not the PSVI expression itself.  By coding this value in the schema 
expression instead of the resulting PSVI, there will be processing 
applications for which the schema adjunct file reference is unavailable.  I 
understand that *all* schema-aware validating processors would be obliged 
to ensure the fixed attribute value obtained as a result of schema-aware 
processing is made available to an application.

And surely a single attribute in the PSVI only for those instance 
constructs containing a coded value is not a significant burden for the 
processing of the instance.

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

Next public European delivery:  3-day XSLT/2-day XSL-FO 2003-09-22
Next public US delivery:        3-day XSLT/2-day XSL-FO 2003-10-13
Instructor-led on-site corporate, government & user group training
for XSLT and XSL-FO world-wide:  please contact us for the details

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)
ISBN 0-13-065196-6                       Definitive XSLT and XPath
ISBN 0-13-140374-5                               Definitive XSL-FO
ISBN 1-894049-08-X   Practical Transformation Using XSLT and XPath
ISBN 1-894049-11-X               Practical Formatting Using XSL-FO
Member of the XML Guild of Practitioners:     http://XMLGuild.info
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc

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