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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: 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" <stephengreenubl@gmail.com>
Date: Thu, April 20, 2006 10:20 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>,
"regrep@lists.oasis-open.org" <regrep@lists.oasis-open.org>,  "CAM
OASIS TC" <cam@lists.oasis-open.org>

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) <david@drrw.info> 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" <stephengreenubl@gmail.com>
> Date: Wed, April 19, 2006 5:07 pm
> To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
>
> 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


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