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

["Sylvia Webb" <swebb@gefeg.com>]

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