Re: [ubl] Minutes of Atlantic UBL TC call 29 June 2005

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Thanks Sylvia

I guess I'm becoming more aware of the need
to consider the implications of XML use on
downstream processing; particularly the need to
fill gaps in how to send a procurement UBL
document between ledger systems along with
the ledger information. This would then avoid
the need to add ledger information to the UBL
instance - avoiding reinventing other standards
(even if the don't have exactly the same design
principles). It means reuse, both of UBL and
of complementary standards in neighboring
domains and the requirement to consider these
relationships, gaps and the best practise for
meeting/filling them. This is about paper clips,
not expensive archiving (that might follow later).

It might be outside the remit of UBL and of
standards such as XBRL on their own but
within the scope of the interrelationship between
them and also the overall scope of general XML,
hence my interest that W3C had something
perhaps helpful in XOP and also XLink. It
is surely in scope how UBL makes use of XLink
and anticipates that others might use it with UBL.

If the overall need is for the StandardDocument
then the question is 'Who should define and
store the schema to it?' Apparently ATG2 have
provided some of the solution but not all of it
it seems to me.

If the solution to this and similar minor problems
(as minor as treasury tags and office stationery
but in their software equivalents) lies in
establishment and communication of best practise
and implementation guides then I would think it
would be the remit of collaborations between
UBL, Tax XML and XBRL with some reference
to CEFACT ATG2 too. I think too that such
collaborations could be of regular importance
as these sorts of issues emerge from growing
adoption.

All the best

Steve




----- Original Message ----- 
From: "Sylvia Webb" <swebb@gefeg.com>
To: "'Stephen Green'" <stephen_green@seventhproject.co.uk>;
<ubl@lists.oasis-open.org>
Sent: Friday, July 08, 2005 3:36 PM
Subject: RE: [ubl] Minutes of Atlantic UBL TC call 29 June 2005


> Stephen,
>
> With respect to your statement "I'd also suggest we might try picking up
on
> old liaisons with XBRL to see how best practise guidelines might be
> developed for the special case of linking UBL documents to XBRL
(especially,
> perhaps, GL) documents."
>
> The Tax XML TC, which I am a member of, has had a similar interest for
quite
> some time. A liaison with UBL and the Tax XML TC and XBRL was started last
> year.  Those discussions have not progressed due to resource constraints
and
> other priorities.
>
> Are you suggesting that this workgroup be revived? Are there more specific
> requirements and stakeholders that you can point to for these discussions?
>
> Regards,
> Sylvia
> -----Original Message-----
> From: Stephen Green [mailto:stephen_green@seventhproject.co.uk]
> Sent: Friday, July 08, 2005 4:08 AM
> To: ubl@lists.oasis-open.org
> Subject: Re: [ubl] Minutes of Atlantic UBL TC call 29 June 2005
>
> > MavisC/MikeG: The NDR editors discussed BryanR's request for an
> >   ANY area.  We don't have an objection to this, but think that a
> >   better solution might be to use the UBL documents as specified
> >   in our schemas and then embed them in a wrapper containing the
> >   data needed for local requirements.
> >
> >   JonB: Or better yet, in another part of the message (for
> >   example, another MIME part in an ebXML message).
> >
> >   StephenG: Or in the CEFACT document header.
> >
> >   AGREED to record this and continue the discussion next meeting.
> >   BryanR is invited to join the NDR editors in their conference
> >   call immediately preceding the Atlantic meeting 13 July.
>
>
> >    Continue the discussion of ANY and the other requests from
> >    BryanR, to wit:
> >
> >       (1) A reconsideration of our prohibition of XSD ANY, because
> >       there are regional laws requiring the inclusion of specific
> >       information, and we need an extensible content area to
> >       handle this; (2) Restrictions on strings in UBL content to
> >       ensure that the content consists of more than white space,
> >       for example through length or minlength facets; (3)
> >       Reconsideration of our prohibition of appinfo, because there
> >       are many cases where one element is conditional on another;
> >       this would give Scehamatron (for example) the data it needs
> >       to do conditional/contextual validation.
> >
>
> I just sent out a message on ubl-dev related to this (coincidentally since
I
> had a similar matter I needed to consider).
> http://www.oasis-open.org/archives/ubl-dev/200507/msg00018.html
>
> My matter concerned not adding data to UBL documents but adding UBl
> documents to other documents (in my case an XBRL-GL document *after* the
> sending and receiving of the UBL message). In this case it seems
appropriate
> to use a header such as SBDH because it isn't a matter of adding another
XMl
> document to UBL, but for some the latter may be an acceptable proceedure.
>
> I suggested that there could be an xsd:type for XML and since it was
pointed
> out to me (thanks Chee-Kai!) that xsd:any is just that.
>
> So I'd suggest we add (or better still ATG2 add) a datatype or set of
> datatypes like 'XMLType' (or 'StructuredDataType', say)
> 1) based on xsd:any or something like it (xinclude?) and/or another
> 2) based on xlink or something like it
> which would allow, completely at the modelers' discretion, the
> 1) inclusion and/or 2) referencing of structured (XML) data in an element
> where it is appropriate to link, add or in some other way associate XML
from
> another schema in a UBL document.
> The metadata attributes (supplementary components) should include the
schema
> information of the linked, included or associated XML.
>
>
> I'd also suggest we might try picking up on old liaisons with XBRL to see
> how best practise guidelines might be developed for the special case of
> linking UBL documents to XBRL (especially, perhaps, GL) documents.
>
>
> Further considerations of how the pitfalls can be avoided
> would be just as much warranted as with the addition of
> the cbc:Note based on xsd:string but this was really a
> modeling issue rather than an NDR one. I suggest this matter
> is similar and by providing the mechanism recommendation
> to the modelers the pitfall considerations can be defered to the
> same too.
>
> All the best
>
> Stephen Green
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>