RE: [ebxml-bp] First cut at a combination of two UBP process definitions

Steve,

 

Thanks for the feedback.  

 

OK - I understand this XPath stuff now - and how the xslt needs the
formatting information it contains - its very xslt centric once
you realize that.

 

This sorta confirms what my feelings are - that we're both going up
the same river, but on different sides of the river bank!

Let's re-visit this again when work on UBL 2.0
second review starts - since it will be much more useful if we can
leverage this XMLPath more widely here - and obviously registry is
becoming more important for UBL as registry implementation work
proceeds.

 

Thanks, DW

-------- Original Message
--------
Subject: Re: [ebxml-bp] First cut at a combination of two
UBP process
definitions
From: "Stephen Green"
<>
Date: Thu, April 20, 2006 10:20
am
To: "David RR Webber (XML)" <>
Cc: "ebXML
BP" <>,

"" <>,
 "CAM
OASIS TC" <>

Hi
David

Thanks for these comments. I hope we might be able to
remember
to ask you to echo them again when the UBL 2 second review
starts.
The XPath name is philosophically correct, so I'm told by
Ken though
I can't claim to understand it well. It just takes a
simple mapping to
create XPath strings from the definition but the
definition can be mapped
easily to other artifacts too. We provide a
sample stylesheet to do the
conversion to XPath strings in either
HTML or text. Cardinality is the
main reason we do more than just
list XPaths as strings - that would loose
the cardinality (multiple
occurance) information which we need the
subset definitions to keep
(and possibly restrict).

Another factor to consider is that by
its guiding priniciples UBL is designed
not to have to be used with
ebXML, so a registry cannot be assumed (nor,
strictly could it be of
course with a purely ebXML solution, I suppose). UBL
does now and
then get asked to include features which could be provided by
ebXML
components but which governments, etc need in some more
independant
means when ebXML cannot be enforced for political reasons
or
economic (not sure of the details). These are similar factors to those
in the
codelist methodology discussion too.

All the
best

Steve

On 20/04/06, David RR Webber (XML)
<> wrote:
>
> Steve,
>
>
At first glance through - this is a very nice and well thought out
example.
>
> I wish I had more time right now to knock out
the VisualScript model for
> this - as what you have is very
nicely setup to create the visual model and
> parameterize it so
its readily re-usable.  (Also - having a tool figure out
>
the IDrefs for you is heaven!).  Probably a couple of days work
tops to get
> it done from what I have already.
>
>
So two thumbs up.
>
> On to other parts - I spotted the UBL
document definitions made reference to
> the XPath definitions -
so I strayed into that URL to see what that is about
> -
>
http://docs.oasis-open.org/ubl/cs-UBL-1.0-SBS-1.0/xpaths/xml/XPath/Invoice-XPath.xml
>
>
This seems a misnomer - as it appears to have very little to do with
XPath
> at all!?!
>
> I keep having this deja vue
with the UBL team - at times it seems we are
> just ships in the
night on different voyage paths - doing the same thing -
> but
different.
>
> This XPath file seems more of an attempt at
a simple vocabulary dictionary,
> with some assembly constraints
thrown in.  In fact it looks like someone
> took the work we
were doing in RegRep on storing nouns and flattened it into
> XML
and threw it out there on a file system - instead of using a Registry
to
> store this information into.  IMHO - this "XPath"
artifact is screaming out
> for being stored in an ebXML Registry
- and in that case you can use the
> registry to do most all the
things this XML is trying to (and then a whole
> lot more
besides!).
>
> Missing off the "XPath" content though - is
each Element parent level entity
> should have an attribute - UID
- that contains the unique domain ID value
> for that thing.
 E.g. Element name='TaxPointDate' UID='UBL010123'  etc -
and
> points back to the EDI notion of dictionary
ID.
>
> This then correlates to the LIN and UID external
identifier mechanisms in
> ebXML Registry.
>
> Beyond
that - I see from the constraint information being provided in
>
"XPath" - that this then takes us over into the work we are doing with
CAM
> and Registry - so that the jCAM processor can look up
entity definition
> usage information and then automagically
apply that at run time to
> processing of XML documents.
 CAM could be easily extended to reference
> these XPath
definitions...
>
> So - the point is I guess - we need some
more liaison to be occurring
> between the UBL / RegRep / CAM
teams on some go forwards.   We can make this
> so much more
compelling and powerful - with just a little bit of effort here
>
- than what this "XPath" definition set appears to be doing right
now?
>
> Cheers, DW
>
>
>
>
-------- Original Message --------
> Subject: [ebxml-bp] First
cut at a combination of two UBP process
> definitions
>
From: "Stephen Green" <>
> Date:
Wed, April 19, 2006 5:07 pm
> To: "ebXML BP"
<>
>
> Hi Monica, ebBP
TC,
>
> I just completed a first cut at combining a receipt
advice notification UBP
> process definition with one for an
invoice, to demonstrate (I hope,
> please correct
> if
necessary) an invoice being triggered by a receipt advice (this
can
> happen by
> the way, but is for illustration of
course).
>
> If I have time I'd like to show an order
cancellation only allowed
> after an order
> has been given
a successful 'order response simple' (with order accepted)
> and
not after a despatch advice. I just think I will need help with
the
> latter,
> more so as I haven't done much of a similar
nature as yet. Plus I may not
> have time before the end of the
week and I guess Monica would like something
> before then - so
here is the simpler one in the meantime.
>
> All the
best
>
> Steve