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


Hi all,
I never imagined so much discussions about this thing ...

My poor opinion is:

1) A document model is designed to represent the way information is
correlated in the real world (nothing more).

2) Every guy has a mummy:  This is effectively causing an endless loop
using object oriented, XSD or other means.

3) The endless loop problem is a software problem, not a human one.

The business side of this issue is related to humans, so we do not care
about loops.

The informatics side is suffering a lot from this, but programmers are
there to put constraints and limits such loops.

The "business informatics" then is the final result... and people is happy:

Welcome UBL !



> 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
>  Date: Fri, June 25, 2010 5:51 pm
>  To: "David RR Webber (XML)"
>  Cc: "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)"  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
>  > 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
>> --------------------------------------------------------------------- To
>> unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For
>> additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123 begin_of_the_skype_highlighting              +39
328 2148123      end_of_the_skype_highlighting
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org




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