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


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

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

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

> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
> Sent: 11 January 2008 03:43
> To: codelist@lists.oasis-open.org
> Subject: Re: [codelist] Comments on CVA spec WD0.2 21 Nov
> 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 am quite happy with that. I was just wondering, not suggesting a change.

> >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"?

Your suggestion here seems to make sense.

> >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?

This is really the last two paragraphs of page 6 and Figure 3. It just reads
as though genericode covers all value constraints. Perhaps if you used the
term "value list constraints" it would be clearer. Ideally, Figure 3 would
cover other value constraints, but this would probably make it messy. I am
currently working on a project where our model is to use W3C Schema for
structural constraints and Schematron for all value constraints and
co-constraints. The value list Schematron will be derived from genericode
files using a CVA file.

> >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.

OK. Or perhaps we could have a solution as you have for "context=" and
"xpath=". Allow both. This would only be worthwhile if we think that many
CVA files will not use masquerading. But like anything with options, this
complicates implementation. What do others think? Incidentally, I had not
spotted on my first readthrough that you could have a reference to a union
of multiple genericode files. This could just be me not reading closely
enough, or it could need emphasising.

> >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 agree that we have a solution that is simpler for many cases, but allows
more complexity where it is needed. It is just a question of whether this is
a good trade-off where the alternative is to have a single construct that is
always a little more complex. I don't have a strong view on it. I would also
welcome other opinions.

> >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 don't have a problem either, but I suspect some will. Would "Association"
work for the element name?

> >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.

I just change the font, as you have here. As I say, a personal preference,
and you have a different preference.
> >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."

I still don't quite understand this. What do you mean by "important"?
> >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
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your
> TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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