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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-hisc message

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


Subject: Reminder of XPath files that will be needed for input specifications


Fellow HISC members,

Further to my earlier comments at teleconferences, I'm strongly of the 
opinion that our committee product will be a set of input specifications, 
along the lines of what we did for output:

   http://docs.oasis-open.org/ubl/cd-UBL-1.0/fs/index.html

As I see it, it is not our committee's responsibility to *implement* an 
input methodology, but merely to equip implementors to be in a position to 
develop input methodologies according to our agreed upon specifications.

As with the output specifications, I anticipate companies and groups to 
release implementations of our specifications in either standards-based or 
proprietary technologies.

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:

   http://lists.oasis-open.org/archives/ubl-hisc/200410/msg00000.html

We need to build multiple candidate input specifications for each document 
type for the different kinds of possible input scenarios we think will be 
worthwhile.

Having committee members develop implementations in parallel with the 
specifications (as I did with XSL-FO stylesheets for output) will help 
validate the specifications.  BUT I do not expect this committee to make 
any implementations as committee products ... I feel very strongly this 
should be the domain of committee members, and I'm hoping that way we'll 
see multiple implementations from different members in order to better 
validate what we write as specifications (something we didn't have for output).

So ... upon what should we base our input specifications?

An obvious choice: - the order and position of the UN Layout Key

Other choices: - a full-screen (large real-estate) presentation
                  with a semantic choice in field order
                - a hand-held (small real-estate) presentation with
                  a semantic choice in field order within constraints

By "semantic choice", I'm hoping we will have input from someone familiar 
with procurement so we can be guided on the order in which these forms are 
filled out when a person has to fill them out one field at a time.

Please think on these issues for upcoming meetings.  I don't want what I 
say to be considered gospel and I would welcome other opinions of how we 
can best serve UBL users.  Please ask around.

And please let's have some email dialogue so that we can work between 
meetings and get the input from everyone as I don't expect everyone to 
attend the teleconferences.

Thanks!

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

--
World-wide on-site corporate, govt. & user group XML/XSL 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 Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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