Re: [ubl-lcsc] xsd:documentation vs xsd:appinfo

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

At 2003-08-27 11:02 +0800, Chin Chee-Kai wrote:
>I think it is about time to start thinking seriously
>about moving data values out of existing xsd:documentation
>and into xsd:appinfo.

It is unfortunate, Chee-Kai, that you were unable to participate in the 
lengthy, contemplative and at times vociferous discussion in Montréal about 
the differences between xsd:documentation and xsd:appinfo.  I think we came 
to a common understanding, especially with Jon's input on a historical 
perspective, of the distinctions between xsd:documentation and xsd:appinfo 
... and that understanding of their purposes is consistent with your 
understanding of their purposes.

I think the disconnect is as ephemeral as perspective and viewpoint.

>I understand during yesterday's LC call that FP's
>code list team

It is coincidence that I am chairing the code list task group, it is 
formally a UBL task group and doesn't "belong" to any of the SCs.

>is looking into where to store their
>metadata, and an outcome will "decide" to some extent
>where the values go.  But I also understand that FP's
>set of metadata relates to presentational metadata,

Yes, we are speaking of non-normative adjunct information targeted for 
"presentation-oriented" applications that need information associated with 
enumerated values in code lists.

>whereas existing <ccts:Component> data values relate
>to modeling and object class metadata.   Both are
>metadata (and so are data instead of documentation),
>but used at different times in different areas.

Ummmmmm ... I see the existing ccts metadata as descriptive information 
appropriately placed in xsd:documentation because it is documenting the 
nature of the information captured in the code list.  In my naïveté I 
didn't think ccts metadata was processable information for applications.

So I don't subscribe to the credo that *all* metadata is by definition 
application-oriented, and my current stand is to support its continued use 
in xsd:documentation (but I am only one of the many members of the code 
list group).

>It is a stated guide for UBL to follow recommendations
>and usage guidelines from W3C.  And XML Schema's
>xsd:appinfo is created precisely for the purpose of
>storing data that usually machines/apps would need,
>thus "appinfo".

And this was clearly discussed in Montréal .. the question came around to 
the existing user base and application features.

>At 2003-08-27 07:20 -0400, CRAWFORD, Mark wrote:
>And we, as NDR determined that the right thing was to avoid the use of 
>AppInfo to ensure broadest market appeal.  I have a business case that 
>says that we will loose part of our audience if we include normative 
>AppInfo in our schema.

This stance in Montréal prompted the code list group to come up with an 
approach that could accommodate all interests.

>So, I'd like to hear if there's any further counter-remarks,
>or remarks on other perspectives that are in favor of
>data being stored in "documentation".

In many ways this is an "eye of the beholder" issue, but I think that NDR 
and LC has had it right all along about descriptive meta data going into 
xsd:documentation ... only when we in FPSC started asking about where we 
could put presentation-oriented information, and the eGov example was 
circulated did the discussion of xsd:appinfo come to the fore.

And, as will come out in tomorrow's code list meeting (thanks to input from 
Eve), there is at least one situation allowed by NDR where xsd:appinfo is 
unavailable to be used for a code list: when the enumeration is 
(acceptably) expressed a pattern instead of a list.

So, in my opinion the only *normative* information in a code list is 
validation oriented (as required by a W3C Schema for constraining values), 
the *descriptive* information is suitably placed in xsd:documentation, the 
xsd:appinfo is *not* available for non-normative adjunct information of all 
expressions of enumerated values, that code list creators cannot be coerced 
into following strict document models for the information we want, that we 
can only produce guidelines expressing the features required of code list 
adjunct files, that we in UBL can safely implement an adjunct facility that 
doesn't interfere with W3C validation (since it isn't validation oriented) 
or get disturbed by existing tools, and that we can successfully produce 
guidelines for code list creators (that we will follow ourselves in such a 
way as to not modify a normative document when the code list creator is 
unable to provide the adjunct information) and have a UBL 1.0 approach to 
this issue.

Let's leave the W3C Schema file solely for descriptive and validation 
purposes, not for the repository of arbitrary (and unending and unforeseen) 
application information.  xsd:appinfo and xsd:documentation provide a 
distinction for two kinds of information that are sometimes kept with a set 
of constraints for validation, and were historically kept with a set of 
constraints out of common practice and belief and were conflated 
undistinguished in ad hoc methodologies, but just because xsd:appinfo is 
there to address this historical perspective doesn't mean it is the only 
way or the "best" way to address the problems we have today in UBL.

At least that is where I stand right now as but one member of the code list 
task group team.

I hope this helps.

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

--
Next public European delivery:  3-day XSLT/2-day XSL-FO 2003-09-22
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