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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: RE: [ubl-dev] infinite loop


Steve,

Actually we do need to make this easy!  Crushingly easy.

This is my day job - to get average developers up and running and using standards based XML exchanges - and I can say this is not easy for them to assimilate - because the average developer with about 5 years experience is the one tasked with implementing this today.  They know what XML looks like - but complex schema - xslt - no can do.

Big hint - their developer tooling will integrate to their back end and build the XML for them - so they do not need your standard XML. If they cannot get your standard XML to work - they roll their own - because that's quicker for them.  Worse - the developer tooling vendor positively encourages that - because it locks them into that platform.  No surprise that the developer tooling will inject all kinds of things into their XML and schema that only works consistently with that vendors platform.  

I know this stuff has been around for 10 years - and is mainstream - but that actually makes it more important to be simple - because people assume that it is - and shock - when its not - they do not use your stuff!  

Keeping the Schema simple - ensures it works with all vendors tooling consistently and predictably - giving interoperability and short implementation cycles.

People knowing your stuff is complex and difficult to do may be job security for UBL consultants - but in the bigger world - just means people are avoiding using your XML and doing it themselves instead, or using one of the other choices out there.

Thanks, DW

-------- Original Message --------
Subject: Re: RE: [ubl-dev] infinite loop
From: Stephen Green <stephengreenubl@gmail.com>
Date: Fri, June 25, 2010 5:51 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "ubl-dev@lists.oasis-open.org" <ubl-dev@lists.oasis-open.org>

OK but even if it is difficult isn't this what we pay software engineers for? I bet it is difficult to process OWL but the tools are still free. Google has no problem with complex XML. We hardly need to handhold people over XML nowadays.
On 25 Jun 2010 22:46, "David RR Webber (XML)" <david@drrw.info> wrote:

Steve,

Unfortunately that is not what I'm seeing.  Mark is correct vis the NDR for schema.

It is very difficult for tools to automatically detect all recursion, and even when they do detect it - how do they handle it?

For example in NIEM the CAM toolkit detects direct recursion on substitution groups - disables the recursive part - but still includes the non-recursive leaf nodes around and inside the node.  That is very highly specialized handling based on knowing how the human architect engineered those groups.  You cannot expect general purpose schema tools to know all that.

Therefore you are creating the very thing you seek to avoid - inconsistency - because you cannot predict how tools will handle the types of recursion in UBL;  ignore it, fail, or partially include components within the recursion?

When you come back to the business needs - which are for clear and predictable exchange structures - I want to woe you back over to the side of simple here!  That is what I believe we heard today.

We should be recommending best practices technically that lead to a good experience for business users - and not one where they cannot understand why the technology is attempting to push them to use constructs that they cannot fathom the purpose or need for.  Again - I believe association references are clear and the normal practice, whereas recursive components are unexpected.

From the modelling stance - I know this can be tricky in really large models such as NIEM and UBL.  In NIEM I have seen recursion occurring simply because the architects added components without realizing that there existed indirect connections that then meant that part is then recursive.  In NIEM this applies particularly to the "Person" entity - which is now 1.5Mb of XML (wow!) - and includes the life history of a person and their travels through administrative systems managing that!

I would like to see modelling and schema tools explicitly warning architects that the new association they are adding is in fact recursive.  However I see why vendors push back at adding that - because it is non-trivial to put into their products.

Bottom line - if you use associations instead of recursion - you avoid all these pitfalls and issues.  

Thanks, DW

> -------- Original Message --------
> Subject: Re: [ubl-dev] infinite loop
> From: Stephen Green <stephengreenubl@gmail.com>
> Date: Fri, June 25, 2010 5:21 pm
> To: "Crawford...
--------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


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