Re: [codelist] Comments on CVA spec WD0.2 21 Nov

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

Thanks, Paul, for your thoughts on this.

At 2008-01-08 09:42 +0000, Paul Spencer wrote:
>Sorry it has taken me a while to catch up, but I have now read this draft.
>
>As a general point, why XPath 1.0, not 2.0?

I felt this was an implementation issue.  As I understand it, there 
is only one available implementation of XSLT/XPath 2.0.  How about I 
replace "XPath 1.0" with just "XSLT/XPath", and then the user can 
choose the level of XSLT/XPath they use in their CVA 
file?  Schematron assumes XSLT/XPath 1.0 and if someone wishes to use 
a different binding language, they have to say that it isn't.

While CVA doesn't need to be implemented in Schematron, it does use 
XSLT/XPath the same way that Schematron uses XSLT/XPath.

I think I'd be more comfortable keeping CVA tied to XSLT/XPath 1.0 
for at least CVA version 1.0, but if the committee decides to allow 
other language bindings, then I'll ask that we have the same 
language= as Schematron and default it to XSLT/XPath 1.0 and allow 
users to specify other binding languages.  Examples of binding 
languages can be seen in ISO Schematron section 6.4: the default is 
"xslt" and the others are "stx, xslt1.1, exslt, xslt2, xpath, xpath2, 
and xquery.

>I seem to remember this one being discussed, but I have forgotten the
>reason. Since the CVA spec applies solely to genericode validation, why is
>the word "genericode" not included in the title?

It doesn't apply only to validation ... but the file format is 
specified to be pointing to genericode files.  Can you suggest a new 
title?  Perhaps "Context/Value Association Using Genericode"?

>In the introduction, there is discussion of three levels of validation:
>structure, value, co-constraints.

You are citing 0.2 21 November in the subject line, but I can't see 
the discussion you are talking about.  I thought that was 
removed.  I'm reading the Introduction on pages 4 through 7.

>But genericode only covers a fraction of
>value constraints. For example, it does not cover a constraint that a value
>must be between 100 and 299. This seems to be ignored in the discussion.

Wouldn't that now be out of scope of a discussion of only the 
association of information items with genericode files?  That was 
discussed in earlier versions of the document before the committee 
asked for the Schematron stuff to be removed.  Have I left in some 
legacy references that should not be there?

>I followed the link to Crane Softwrights resources at the bottom of page 7,
>but did not find anything relevant initially. The link to the correct page
>on the site needs to mention genericode and CVA.

Good point!  The page has just been updated.

>I think the use of mixed model has been discussed. I hate it in this type of
>document. I would only allow mixed model in external namespaces (such as
>XHTML). It is easier to read and easier to process without it.

Granted, and I've addressed this in the latest draft that I'm working 
on.  There is now no mixed content for documentation.  I'm using the 
same annotation constructs as in genericode.

>CVA uses a relational model with separate ValueList and Contexts. I can see
>that this saves text in rare cases where a masqueraded list has multiple
>references, but otherwise it just complicates things. Is it necessary? I
>would prefer to see the two combined into something like:
>         <Association item="@item-a" values="enumeration2.gs/>

I think the design is necessary.

Consider the situation where the same genericode file is needed by 
two different contexts.  In your suggestion, there would be two 
<Association> elements each pointing to the same genericode 
file.  But if masquerading meta data were needed for that one 
genericode file, then that would have to be specified more than once.

Since each code list can have its own documentation and masquerading 
meta data, and different items will be using the same code lists, I 
think the separation is absolutely required.

While I know spaces are not supposed to be in URI strings, how would 
your suggestion for the values= attribute specify the union of 
multiple genericode files?

I feel that what I've proposed follows good XML design practice.

>I understand the use of the context and xpath attributes, but do we need
>both? Would it be less confusing if we dropped the context attribute?

I'm anticipating most people will find context= all that they need, 
and that xpath= would be used in only rare occasions.  I'd like to 
hear if other committee members think we should have only one 
attribute instead of two.

>I also wonder if it will be confusing to some to have a Context element and
>a context attribute.

Point taken ... can you suggest a replacement name?  I hadn't 
considered the potential confusion of having both the element and 
attribute name the same.  It is obvious that I don't have a problem 
with it, but I'm too close to it by now.

>I kept looking at the example on page 10 looking for an example of the use
>of the xpath attribute. There isn't one.

I see it in the third <Context> element.

>The penultimate para of page 11 ends by mentioning two mutually-exclusive
>attributes. It would be useful to name them here.

Okay.  Done for the next draft.

>A personal thing - I dislike using angle brackets round element names.
>"<Context>" is not an element - it is a start tag. Similarly "item=" is
>neither an attribute, nor an attribute name. As I say, this is personal
>preference. I don't think  OASIS has a guideline on this.

Does anyone else have a better way of talking about elements and 
attributes in prose?  I've successfully used this convention in my 
training material for many years.

>Does the xpath attribute always specify a single information item? This is
>the implication of the last para of page 11.

No ... it merely specifies a more specific context than the context= 
address.  I've just changed the wording to "of the information items".

>Last para of page 12. Should this be non-normative? Perhaps a normative
>statement is needed as well to describe how multiple references to the same
>information item are handled.

I wrestled with that but made it normative because it is an explicit 
directive to implementations regarding how to process the 
declarations.  I've just changed the wording to be from the 
perspective of an application:

"It is possible that regardless of which combination of attributes is 
used, two XPath expressions will both match the same node in the 
source document.  The order of <Context> elements for the 
context/value associations is interpreted such that the more 
important XPath contexts are found first and the less important XPath 
contexts follow. Thus, a given information item from the document can 
be associated with only a single document context declaration in this 
context/value association file."

>The note on page 13. I was not sure what this added.

I grant that it is tutorial in nature, but it is not obvious to the 
casual user of XPath.  It could be very useful to a user of a 
vocabulary with many documents (such as UBL) where a single set of 
constraints is managed in a single CVA file, and that file 
simultaneously supports those constraints in many document models, 
and some document models are treated differently than others.  If the 
casual user doesn't think to use XPath in this fashion, they may feel 
obliged to solve the management problem in a way that requires 
multiple files and more machinery.

>p15. Mixed content again. This could easily be removed.

Done.

>Appendix A. Is this needed?

Again I grant that it is tutorial in nature.  I don't think it is 
"needed" but I do think that for the audience considering this 
specification it would be very helpful.  I'll remove it if others 
also think it should be removed, but I'll leave it if others think it 
helps the reader of the CVA spec portion.

>That's it. Some minor comments, some rather more major. I look forward to
>some responses.

I *very* much appreciate this feedback, Paul.  I'm glad to consider 
any changes and I'm happy not to be the only one thinking about the 
technical aspects of the specification.  The more we can work out 
between us, the less problems we'll hear from users who consider it.

Would other committee members please consider Paul's points and my 
comments on them?  The sooner you can post your own comments, the 
sooner I can get the next draft complete.  Perhaps in time to have a 
teleconference on the 22nd.

Thanks again!

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

--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
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 Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal