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: <xsd:documentation> --> <xsd:appinfo> & metadata


There's been some discussion within FP on recognising
that certain presentational metadata should rightly
be classified as first-class values as the values are
mostly used by transformational scripts, programs, etc.

Likewise, in the course of generating the schemas and
doing some transformational work myself, I find it 
increasingly more appropriate to move all the elements
within the current <xsd:documentation> to <xsd:appinfo>
because those token values and even brief definition 
strings are much more applicable inputs to machines
than mere descriptive prose meant for human beings.

Moving to <xsd:appinfo> doesn't mean that human's cannot
read the same metadata;  it's just to recognise the 
status of such token and string values, and not to
accidentally discard them as mere harmless discardable
documentation during processing.

It also does not mean setting a rule saying we now use
only <xsd:appinfo> and no longer <xsd:documentation>,
as we're just trying to vacate current resident elements
to <xsd:appinfo>, leaving real English sentences 
in <xsd:documentation> (in whatever appropriate format,
such as XHTML, etc).

At the same time, FP is also beginning to structure 
some elements to be contained within the <xsd:appinfo>
under the overall FP parent element <ccts:Presentation>.  

We haven't discussed yet if it should become necessary 
to start allocating unique namespace values to FP's
<Presentation> and LC's <Component> and any further
additional metadata groupings.  But my rough thought
now is that we need not waste too much time on that
aspect at the moment since the element names are very 
local to FP & LC and we can easily make unique any 
remote need when local names clash within UBL.

I can see contextualization needs that may require 
"parking" some metadata in the <xsd:appinfo> space.
Those could use other namespace values and prefixes 
and would be out of current scope of discussion.



So, I'd like to suggest, by way of example, to perform 
the following change in all the schemas:

-----------------------------------------------------


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