[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [codelist] Re: Updated genericode specification
From the perspective of our work on information exchange,
interoperability will require conformance testing that a document which
purports to comply with the specification is valid, and that an
application which purports to accept a genericode document as input
successfully interprets that document as intended - both reading the
syntax and interpreting the semantics. You may also have a third case,
where you need to check that an application which purports to generate
genericode documents does in fact produce compliant syntax and
semantics.
Howard Mason
Corporate IT Office
Tel: +44 1252 383129
Mob: +44 780 171 3340
Eml: howard.mason@baesystems.com
-----Original Message-----
From: Anthony B. Coates (Miley Watts) [mailto:abcoates@mileywatts.com]
Sent: 05 September 2007 15:47
To: Code List Representation TC
Subject: Re: [codelist] Re: Updated genericode specification
*** WARNING ***
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
We are simply chasing our tails here. If we are going to get to some
resolution of this thread in finite time, we need to stop arguing at
cross-purposes.
In particular, we simply aren't agreeing from the outset as to what
*conformance* is, and what the scope of it should be for the genericode
specification. Although this is only marginally less vague a topic than
many of the great philosophical questions of history (like what "love"
is), we still need to get to a sufficient agreement on what the question
is or we will never agree what the answer is.
It's become clear to me that Ken and I have different views on how much
of the "code list lifecycle" should be covered by the conformance.
Ken's view seems to be (and forgive me for paraphrasing) that the
important part of the lifecycle is the authoring of genericode
documents, and that if those are valid and self-consistent, then
anything that happens after that is somebody else's problem.
By contrast, my view is that we need to be concerned not only with
whether genericode documents are valid, but also whether applications
process the genericode-specific parts of the information content in a
consistent and repeatable way. Users are free to put all kinds of
information in
genericode documents, and interpret their own information as they like.
However, the same code list (which may span multiple genericode files
due to references) should not, in my opinion, appear to contain
different information depending on which application opens it (excepting
differences due to applications having different local copies of the
same genericode file). For that reason, I believe that interpretation
of the "structural semantics" (for want of a better expression) of
genericode is an important and valid part of the scope of conformance,
because it impacts directly on users perceptions and measurements of
whether they get consistent behaviour from consuming applications or
not.
I also disagree with Ken's brief explanation of what conformance is
(i.e.
a short check list of the major points from the spec), and I don't think
that is how OASIS would define it. I know the check list approach was
mentioned as one possible interpretation, but I suspect that the
inclusion of conformance as a separate issue for OASIS specs has been
driven by Web services and the like, where it has not been uncommon see
different implementations all adhering to the written specification, but
via differing interpretations that are not interoperable. This kind of
problem is no less important for genericode users.
Anyway, how about we start with discussing how much of the "code list
lifecycle" we can and should cover with conformance clauses? Once we
agree on that, I think some of the answers will come more easily. By
the way, part of the answer could be that we end up splitting the
conformance clauses into "authoring" and "processing" sections, so that
nobody feels duty bound to try and comply with conformance clauses that
aren't relevant to the part of the lifecycle that they are responsible
for.
Cheers, Tony.
On Tue, 04 Sep 2007 17:41:21 +0100, G. Ken Holman
<gkholman@CraneSoftwrights.com> wrote:
> At 2007-09-03 22:09 +0100, Anthony B. Coates (Miley Watts) wrote:
>> On Mon, 03 Sep 2007 18:48:12 +0100, G. Ken Holman
>> <gkholman@CraneSoftwrights.com> wrote:
>>
>>> (1) - is it appropriate to include "must not be used as a de facto
>>> location URI" statements? Is that not out-of-band of the
>>> specification?
>>
>> I don't think it is out-of-band. The point of conformance clauses is
>> to make sure that application behaviour is predictable and consistent
>> and not dependent on individual interpretations of a specification.
>> (1) is important because the interpretation of a genericode code list
>> could
>> differ in two applications if they use the various URIs differently.
>> When
>> I originally wrote my genericode draft, I was seeking to explicitly
>> to avoid doing the same as W3C XML Schema, which has oft been
>> criticised for its use of namespace URIs as de facto Schema lookup
>> URIs.
>
> Here is what we are beholden to according to the process document:
> http://www.oasis-open.org/committees/process.php#transition_2_18
>
> "A specification that is approved by the TC at the Public Review
> Draft, Committee Specification or OASIS Standard level must include a
> separate section, listing a set of numbered conformance clauses, to
> which any implementation of the specification must adhere in order to
> claim conformance to the specification (or any optional portion
thereof)."
>
> The "implementation" to me is the bits and bytes of the file format.
> I claim a particular file I've created conforms to genericode. The
> specification describes the properties of the file. If I create a set
> of genericode 1.0 files for UBL I have no thoughts about the
> applications acting on those files, I am merely ensuring the bits and
> bytes in the file conform to the specification.
>
> Looking at page 56 of the August 28, 2007 draft, looking at the third
> context (BTW, these need to be numbered according to the text above),
> I
> read:
>
> An application must signal an error to the user if it is
> not able to retrieve a code list document to match the
> code list reference.
>
> My suggestion in the meeting was to turn this same conformance
> requirement around to focus on the file format and not the
> application, using wording along the lines of the following:
>
> A genericode file code list reference points to a
> conformant genericode code list document.
>
> As Jon pointed out, this is more declarative than procedural. It is
> stating what constitutes the conformance of an instance of genericode.
> An application can then decide what to do if it is dealing with an
> instance that is not conformant: it can just stop, it can report an
> error, it can do some fallback behaviour with other files .... we are
> not obligating the application "must signal an error to the user"
> because what if it doesn't want to but wants to do some other
> behaviour because the file is not a conforming genericode file?
>
>>> (2) - "xml:base does not apply to canonical URIs" seems related to
>>> use, not specification
>>
>> Same as (1). This is what conformance is all about, making sure the
>> information is interpreted the same way by different applications.
>
> I disagree. I think that is what the specification is about. I think
> conformance is a check list of the specification but does not replace
> the specification or add anything new. It could even cite chapter and
> verse so that someone reading the conformance clause can go and get
> more information. Looking for chapter and verse for xml:base I see on
> page
> 29 the same wording you have above. If this is important to bring out
> in conformance, then a conformance clause might read "all canonical
> URIs have not incorporated xml:base" or some such in order to focus on
> the canonical URIs themselves.
>
> For another example, looking at my suggested rewording above, section
> 3.5 on page 23 states "Each of these [CodeListRef elements] is a
> reference to a code list or to a version of a code list". That is the
> specification requirement against which conformance is measured ... I
> don't think we have to say anything about application behaviours. My
> wording above covers the specification statement.
>
> I now acknowledge the recently added text to the genericode
> specification has application behaviours (I just found them doing a
> search) that are echoed in the conformance clause. I had missed this.
> I am of the opinion it doesn't belong.
>
>>> (3) - if we are to include "An application must ..." statements (I'm
>>> not sure we should) then the opening paragraph of 4.4 needs to be
>>> augmented with something like: "including the following auxiliary
>>> rules imposed on a genericode instance or an application processing
>>> a genericode instance:"
>>>
>>> The reason I'm hesitant about "An application must..." statement is
>>> that we aren't defining a specification like XSLT with a processor,
>>> we are defining a data format. Is it up to the specification to
>>> impose such constraints on how the data is used?
>>
>> We aren't constraining how it is used, rather how it is interpreted.
>> It's
>> all about ensuring that the details of a code list are never
>> ambiguous, that the values don't depend on which application you are
>> using to interpret the code list. It's not telling the application
>> how to use the information, just how to interpret it consistently and
>> correctly.
>
> Then let's state it in terms of the genericode file as to what has to
> be true *about the file* that it will be unambiguously interpreted
> consistently and correctly.
>
>>> For example, if the file at a LocationURI changes arbitrarily, that
>>> changes the conformance of a given genericode instance according to
>>> this conformance clause. I think it is enough *for conformance*
>>> that the LocationURI be correctly formed regardless of what it
>>> points to. What if, say, the user is acting locally without an
>>> Internet connection ...
>>> the content at the external location is unknown ... does this mean
>>> the conformance of his instance is unknown?
>>
>> There needs to be consideration of what happens for an offline
>> machine, which may not be able to retrieve some location URIs, but
>> should still work through the list looking for a local URI that it
>> can resolve. It is important that we discuss what should be expected
>> to be retrieved from location URIs, since the interpretation of a
>> code list depends critically on any external column sets or code
>> lists that it refers to.
>
> Then the specification can state what the interpretation of a
> genericode file is in the presence and absence of a resolved URI
reference.
>
> Looking at it from the perspective of a user of genericode: how I can
> commit to the UBL TC that the genericode files I create for them all
> conform to the genericode specification if it is up to an application
> acting on it to measure conformance in real time? Say I have a code
> list reference to an artefact sitting on the OASIS server. The
> genericode file is a conforming genericode file because the artefact
> at the URI reference is valid. If the artefact were absent, then it
> isn't. I can accept that. But if an application acting on the
> genericode file happens not to be able to access the artefact that
> does exist, does that make my genericode file non-conformant? I don't
> think it does.
>
>>> So does it make sense to only include in the conformance section
>>> clauses that apply to the instance as a standalone artefact, and
>>> move other issues to a "guidelines for applications" section and
>>> make it non-normative?
>>
>> No, because the things I've outlined are necessary for conformance in
>> the sense of consistent interpretation of code lists in genericode
>> format.
>
> Please let us discuss this some more. I am not swayed that we should
> include application behaviours in the specification and conformance
> clauses. I think the specification should state the interpretation of
> the file format in terms of the file contents.
>
> I'm still of the opinion phrases like "an application must signal an
> error to the user" are not appropriate for a file format
specification.
>
> Even the XML specification is a specification of the information
> delivered to an application from a stream of bytes: "Extensible Markup
> Language, abbreviated XML, describes a class of data objects called
> XML documents and partially describes the behavior of computer
> programs which process them."
> (http://www.w3.org/TR/2006/REC-xml-20060816 section 1.0 Introduction)
>
> If genericode is to include application behaviours then these should
> be in the scope, in the specification proper and then can be cited
> from the conformance clauses. But I'm not yet convinced.
>
> Would others with an opinion on this please comment? I will back down
> if others do not agree with my comments, but I think this needs more
> discussion.
>
> Thanks!
>
> . . . . . . . . . . . . Ken
>
> --
> Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
> 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 Jul'07 http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>
--
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]