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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Re: [ubl-ndrsc] MINUTES: Joint NDR/LCCSC 4 Feb 2003




As a follow-up to Tim's reply to the Join LCSC/NDRSC minutes.
First of all, I add my thanks to the minute preparers.
I notice that they are so accurate that they reflect my failure to correct
the misconceptions that several attendees held in response to a "10
secound" review of Ken and other's document.  Tim alludes to the
misconceptions in his reply.
Nevertheless, the Concept and Methodology team did not present any
direction, and instead suggested that we wait for the next issue paper and
that a discussion of the LCSC mail list traffic would not be a productive
until after the issue paper is released.  It was also noted that efforts to
apply any UBL extension methodology to instance documents was a terribly
wrong approach (I don't think any of us disagreed.) As this was the
starting point of the meeting, I saw no need to enter into further
discussion on context/methodology.  I had the distinct impression the the
Context team had a clear vision of what the paper would consist and that
they were confident it would provide a proper technical solution.

The only other thing that I would like to add to the minutes message and
Tim's reply is on an action item for the LCSC proposed by Jon that does not
show up, but follows the cut and paste below.
"
Jon's proposal:  We can not publish schema without comments, we don't want
to publish a huge schema with everything as our schema.  My suggestion is,
what is in the spreadsheet is what goes into the schema.


Tim's Reply
my take on this is that the XML schemas are themselves metadata, they
describe the model of our data.  As such they are logically equivalent to
the spreadsheets and the UML diagrams.  it is just that the XML schemas are
more machine processable representations.
Remember we only use spreadsheets because of ease of maintenance, but the
trade off has been the perl-script coversion.  this debate has been spurned
by that strategy.  I dont' have a problem with the extreme view - where a
schema describes the entire conceptual model.  One day we want to remove
the need for spreadsheets and XML schemas are the obvious way to go.
maybe what we are looking at is a single schema that describes the entire
normalized model and then  a context methodology that asemebles specific
document schemas (based ont heir conetxt drivers).

ps personally, i am not sure any annotation needs to be normative - the
documentation does not immediately impact interoperability.

"end cut and paste

Addition

Jon also proposed that the LCSC be responsible to make sure that:
1. All "annotation" in the spreadsheet be normative *only* (which means
that LCSC would remove all from the description column that is not
normative.
2. (From M. Crawford) All annotation comply with the latest CC Spec for
annotation.  (I'm not clear on the impact of this)

I would invite LCSC members to consider the action items proposed and
address any response to the LCSC mail list.

Thanks,

Marion







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


Powered by eList eXpress LLC