Re: [ubl] Question regarding ebBP

[Tim McGrath <tmcgrath@portcomm.com.au>]

something is confusing me about this request.  probably because i am 
unclear on the use of "logical document". 

firstly, what do they mean by "logical"? my understanding of a logical 
document is that it is an abstraction of a physical one.  this doesn't 
fit with the rest of the disucssion which deals with physical artifacts.

secondly, do they mean "logical document" or "logical document model"?  
a logical document would be an abstraction of an instance.  a schema is 
not a logical (or physical) document - it is a model of a physical 
document. so we can say (in a process definition), "here is a logical 
document" (the idea of an invoice instance) but what you are describing 
is "here is a physical document as expressed by this schema (and other 
stuff)"

from what you describe, i first thought that when ebBP says "logical 
document" they expect a model of a logical document.  this may be a UML 
model, and/or a UBL spreadsheet, and/or a narrative description and/or 
an abstracted schema. however, the artifacts we know as UBL Invoice 
schema is not a logical model of anything. 

however, your request clearly wants a physical document model - not what 
the term "logical document" implies.

Stephen Green wrote:

>Greetings,
>
>I was asked on the last ebBP (ebXMl Business Process) TC 
>call to put a request to UBL members:
>
>Background
>
>We have been looking at how to use the latest public review
>draft of the ebBP version 2.0.1 to specify, in particular, for
>example, UBL logical documents in a business process. By
>logical documents is meant not so much the various imported
>XSD schemas necessary, say, among other schemas, etc in
>a document but the overall document such as a UBL Invoice.
>However I have commented that in order to specify what is
>meant by that logical document, in a real, typical situation, it
>would be necessary to specify more than just the document
>schema (e.g. ...UBL-1.0-Invoice.xsd) but also other artefacts
>defining the document such as any formal subset and possibly
>a set of codelists - most of which might not necessarily take
>the form of XSD schemas but could include Schematron
>schemas and other XML documents. These together would
>constitute the definition of the logical business document, 
>though usually the main artefact would be, in UBL's case, the
>document XSD schema. ebBP indeed provides several 
>occurances of an element //Specification for each logical
>document to cater for this. 
>
>The 'Specification' element in ebBP 2.0.1 so far has attributes for 
>'location' and 'type' of a schema or other document-defining 
>artefact. Also there is a 'targetNamespace' attribute which is 
>optional and obviously applies primarily to those types of artefact 
>which include the specifying of a targetNamespace. I have 
>commented that it would make sense to cater for artefacts which
>do not have their own, specified targetNamespace by adding 
>a further attribute to allow the specification of an appropraite
>identifier for these in addition to the 'location' and schema 'type'.
>
>
>Request
>
>My example backing up my comment would likely be the UBL
>Small Business Subset which has its own identifying urn but does
>not provide any namespace other than the corresponding UBL
>document targetNamespace. 
>
>Would anyone provide another example, perhaps for codelist
>documents or the like, either for UBL or any EDI-related situation?
>
>Such an example might include the attributes 'location' and
>a new attribute, say called 'ID' to point a 'Specification' element
>(in an ebBP definition instance) to one of several artefacts which
>define a logical business document. Perhaps a set of Specification
>elements could together be provided to define a single logical
>document. The more realistic the better I guess. Maybe the 
>'location' attribute would in some cases be sufficient or just that
>and the optional 'targetNamespace' attribute, if appropriate.
>
>Any help would be appreciated. Thanks.
>
>All the best
>
>Stephen Green (as ebBP TC/UBL TC liaison)
>
>
>
>---------------------------------------------------------------------
>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 
>
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476