[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-hisc] Reminder of XPath files that will be needed forinputspecifications
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]