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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] UBL / XForms Re: [ubl-dev] Simple ODF/XForms (OOo2/SO8) for UBL 1.0 Invoice


Bryan

The UBL schemata are so big that you'd
probably want to concentrate on supporting
the SBS (at the most).
Then there is the problem with there being
no official * schemata * for the SBS (it
defers to the UBL schemata deliberately).
The answer might be a combination of use of
UBL SBS examples (generated ones in the
SBS package might be preferable) for the
content of the XForm and then somehow getting
the corresponding definitions from the official
UBL schemata (if you choose to include them,
say as hover help messages).

All the best

Stephen Green

----- Original Message ----- 
From: "Stephen Green" <stephen_green@seventhproject.co.uk>
To: <ubl-dev@lists.oasis-open.org>
Sent: Friday, December 23, 2005 1:56 PM
Subject: [ubl-dev] UBL / XForms Re: [ubl-dev] Simple ODF/XForms (OOo2/SO8)
for UBL 1.0 Invoice


> [reposted due to apparent mailserver problems]
>
> Re: http://www.oasis-open.org/archives/ubl-dev/200512/msg00024.html
(simple
> invoice forms for ODF/XForms with OOo2)
> and http://www.oasis-open.org/archives/ubl-dev/200512/msg00021.html (about
> development of a set of pure XForms for UBL)
>
> A colleague's comment to this and to Bryan's question:
> localization: it is important (learning from EDI) to attach
> the normative semantic definitions to the input fields
> so this would be well done by having the hover help
> messages for each input field containing the normative
> definition of that element/BIE. This leads to the localisation
> need that the UBL data definition dictionary be used by
> those concerned to produce either a multinational,
> sophisticated set of XML forms which have a localization
> option or a separate form/set of forms for each locality
> (one in Chinese, one in Korean, one in English, etc).
>
> I expect Bryan, you'd prefer to stick to the English forms
> and leave others to internationalize them. But adding the
> defintions as hover help messages might be a good idea
> (though a lot of work).
>
> Obviously a labour saver for things like XForms localization
> and even for customization (*) would be to generate the
> XForms with XSLT from the UBL schemata. I've tried this
> before quite successfully. The end result is rather too
> bland and generic though so a two step process of
> first generating basic XForms then improving them
> manually perhaps or if you're adventurous of delegating
> the look and to CSS stylesheets with just the generated
> XForms, either would be a good idea I think. * - this helps
> customisers who, if supplied with the XSLT could probably
> get a good result even after customisation. Likewise with
> minor versions I would hope.
>
> I have had problems with this coping with changable
> namespaces when writing the XSLT. Maybe XSLT 2 would
> be a good option. Maybe you won't get a problem. I was
> thinking of one XSLT stylesheet for all the UBL Docs/schemata
> (which might work with customisations and minor versions too)
> but at worst it might be you need to manually change the
> namespaces in the XSLT stylesheets. Perhaps there is a way to
> not have to include the namespaces in the XSLT.
>
>
> All the best
>
> Stephen Green
>
>
>
>
>




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