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] | [Elist Home]

Subject: [ubl-lcsc] Quick NDR comments on the 0pt65 work

Hi LC folks-- The NDR group met today and spent some time reviewing the 
internal 0pt65 draft of the schemas that Gunther made available.  We 
noted some issues as we went.  In the hope that these can be 
considered/addressed before your August 16 deadline, we include them 
here.  (They also appeared in our meeting minutes from today.)

Please let me know if you have any questions or wish to discuss further 
with the NDR group.  Thanks!


			*		*		*

    In reviewing the 0pt65 XSD draft just sent out by Gunther,
    we noticed the following issues.

    - Wrapper for LineItem*:

      Between 0pt64 and 0pt65, we noticed that the Details element
      that had wrapped the series of LineItem elements had disappeared,
      and learned that this was because all the parts of the element's
      name (Order, Details, etc.) needed to vanish according to our
      naming/truncation rules.  It was not our intent for the naming
      rules to have substantive effect on choices of whether elements
      should exist! :-)  We recommend that a wrapper element be added

      There are a number of ways this could be done, intersecting
      with our existing recommendations in various ways.

      * One way is to simply pick a different property term and
        qualifier for this one wrapper element, keeping in mind how the
        naming rules get applied to ensure that the element name doesn't
        get "zeroed out."  (This smacks a bit of gaming the system.)

      * Another way is to consider how to handle the NDR Containership
        paper's recommendation to always add intermediate containers
        around series of like elements (such as LineItem*), and apply
        it -- whatever it is -- to this situation.  Given the initial
        feedback we've received on this paper, this would probably
        mean adding back a row for not only this instance but other
        cases of element-series.  It would also probably mean applying
        a naming rule in all cases that doesn't really exist yet:
        Should the element name net out to LineItemList?  LineItemSeries?
        LineItemSet? and how would this work with our tripartite naming
        scheme? and do we want to reflect the significance of series
        ordering in this rule (e.g., set vs. list)?

      As a reminder, the motivations for having wrapper elements around
      element-series are that (a) it gives a place to hang metadata and
      extensions that apply only to those elements and not their other
      siblings, and (b) it makes certain obvious kinds of processing
      easier and more natural (e.g., applying processing to all children
      and grabbing the first and last elements).

    - ID/identifier naming

      The automatic application of the naming/truncation rules related
      to the Identifier representation term almost work, but there are
      inconsistencies.  First, the truncation should be from Identifier
      to "ID", not "Id".  Second, in many caes the truncation doesn't
      seem to have been applied at all.  An analysis is needed to
      determine whether the spreadsheet formula is at fault, or whether
      particular column fields need adjustment.  (It appears that all
      cases of elements called merely "Identifier", with no prefix, are
      uniformly not shortened.

    - No top-level elements

      In contrast to 0pt64, the draft of 0pt65 seems to be missing
      declarations for top-level elements for Order etc.

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com

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

Powered by eList eXpress LLC