Re: [ubl-hisc] Reminder of XPath files that will be needed forinputspecifications

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Greetings HISC

Ken wrote:

"These specifications must, therefore, be technology-agnostic.

This was accomplished for the output specifications by focusing solely on 
the XML of UBL, not on any presentation or transformation technology.  For 
UBL 1.0 I published the complete suite of possible XPath addresses for 
every possible element and attribute in all eight document types:"


But to be honest, though I like the idea of limiting the scope and allowing
individuals or companies to develop things further (as is inevitable - just
a question of where to draw the line) I'm not enirely convinced that XPath
is more technology neutral than say XForms.

As I say, isn't it just a question of where to draw the line?

I do think we have to keep to the general tenets we have laid down already
in keeping our approach to a W3C agreed technological path - important, as
our NDR Spec says, in order to keep UBL in harmony with such standards
work for the better stance of UBL in the future. Keeping in line with UNECE
and hence the UN Layout Keys seems prudent too. But as Ken has pointed
out, these were not really designed for the kind of work we are doing exactly
and we may need to progress a bit beyond the Layouts.

At that point we are on our own rather, though UNeDocs may help. We have
to accept a bit of a position of leadership here and move the standard forward.
My own views about there being a potential starting point short of implementing
or specifying implementations of the whole of UBL at once, this view I've embodied
in the ubl lite profile which I have put forward as a contribution (including input from
other groups such as UK Gov's Office of Government Commerce and work by
individuals such as Mike Adcock) to that business content which I believe is most
essential and in some ways sufficient for the starting point. This goes beyond 
layout to business content and so goes somewhat, *I think*, beyond the UN Layout
Keys. This is because the ubl lite profile seeks to provide both for visual content
and business/data/processing('downstream') content.



I've a few questions I think might want asking and some points to note:

Should a visual implementation provide just for the data typically 
presented in a paper-based document? Should, for instance, it also provide
for the visual display of that data which might be irrelevant to a paper document
but be necessary to an electronic document such as 'DocumentStatusCode' and
other codes and identifiers?
For input such data might be added invisibly but would nonetheless be necessary
in the output document. In one implementation it might be that a Web Service obtains
and adds the OrderID(s), say.

Then there might be questions to consider for many individual ABIEs/Types
eg. for AddressType
2. Should all of the AddressType be input visually or should say a country code be added
invisibly? 
3. In presentation of an Address, should there be an effort to always display all of the address
or just that part sufficient to uniquely identify it (which might just be an ID)? - e.g. does
the country code need to be displayed when the country name is available and may suffice?

One could go through all of the ABIEs (types) in either the whole library or just a subset
such as those in UBL 1.0 fp Xpaths or ubl lite's library and ask similar questions, asking
some literally to the business domain experts, say. Low hanging fruit might be found in
those ABIEs/Types containing only BBIEs/'leaf nodes'.

One shouldn't forget to include the attributes of BBIEs - should all of the attributes of a
CodeType, say, be exposed for user input? In some cases this is easily answered in that
there are fixed value attributes (e.g. for CurrencyCodes) which could be added invisibly.
UBL lite doesn't yet provide for subsetting of the attributes. This was just my feeling that
they should all be included to keep things safer for the legal aspects of the documents
(avoidance of ambiguity regarding Codes, etc). But, as I say, not all need be made visible
to the input clerk.

Then a key point / question is (in my opinion): Should HISC specify *likely* groupings
of entities to suggest that a form should keep them visually together - e.g. might all
the Address components be kept together but not necessarily all of the Tax components.
This again could be asked of each ABIE/Type in turn (perhaps, as I say, starting with an
agreed subset like the Layout Key or the ubl lite profile reusable spreadsheet).

I'd also note that if ubl lite is used, it could be extended beyond the order and invoice alone
but in doing so I'd suggest creating a separate 'reusable' spreadsheet subset for each
document since, say, a ReceivedDate might be required in the Delivery ABIE of a Receipt
Advice (not even sure if it is in the Delivery ABIE mind, but just to illustrate) but a different
date required in a Despatch Advice. However, keeping to the same ABIEs as in the order
and invoice subset as much as possible would seem sensible.



Hope this is the sort of thing Ken is asking for. Sorry I can't get along to meetings (Europe time).

All the best

Stephen Green