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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] Global vs. Local -- Gunther's Recommendation


Wow, this has been a very educational thread for me!  I still have some 
questions, though:

Dave Carlson wrote (sorry if the wrapping is bad):
 > The most difficult problem is with mapping (in UML) a global element 
to the
 > namespace in which it is declared.  The global element may be 
declared in a
 > different schema module, and possibly a different XML namespace, than the
 > complexType or simpleType on which it is based.  Some XML Schemas 
(e.g. ACORD)
 > use one very large schema file in one namespace; global elements are 
quite
 > straightforward here.  Other schemas (e.g. OAGIS 8.0 and 8.1) use a 
very large
 > number of schema modules to support reuse and abstraction, which greatly
 > complicates mapping global elements to schema modules and namespaces. 
  UML has
 > not yet settled on a rule for determining schema document modularity 
and their
 > namespace assignment.

But if UBL has only reusable types, and not reusable elements, then 
anyone building a new document out of UBL types will have to bind their 
own elements (in their own "foreign" namespace) to types in UBL's 
namespace, which is the skew I referred to earlier.  (Or I suppose they 
could trivially derive a native type from a UBL type every time they 
want to use something from UBL, but that doesn't seem so practical 
either.)  Is this a problem in practice for UML/OO processing?  (I think 
it may be a problem for those creating and trying to understand 
instances, and also for those trying to reuse any non-type-aware -- say, 
XSLT/XPath V1.0 -- software to process the new documents.)

Stig Korsgaard wrote:
 > What is really there is acutally the support for Venetian Blind and the
 > opportunity to both locally and globally define elements not only one 
or the
 > other!

If I'm understanding correctly, in your first post you seemed to say 
that Venetian Blind gives you the ability to make elements global at 
will so that you can reuse them, but above you're correcting that 
misimpression.  It can't be done with XSD unless you generate both 
global and local element declarations from the spreadsheet, right?  (We 
did discuss this in the NDR group, believe it or not.  I suppose it's 
still a possibility.)

Stuhec, Gunther wrote:
 > we in the core components group agreed last week that for leaf
 > elements only data types are reusable and the BCCs as well as BIEs are
 > not reusable. That means, it makes no sense if we're defining global
 > declared elements for all BIEs and BCCs, because this will be used in
 > aggregations only and this
 > is the local element approach. And "data types" should be defined as
 > global declared and reusable types. I hope, all are agree with this
 > statement.
 >
 > I would like to say, this will be the "Garden of Venetian Blind" now
 > (All data types are defined types, all BIEs and BCCs are defined as
 > local defined elements, all ACC are defined as global declared types
 > as well and all ABIEs could be defined as global declared elements
 >
 > The question is now, should we define global declared elements for all
 > aggregations (ABIEs and ACCs?). This means. As Dave Carlson mentioned
 > that the "pseudo-classes" of global declared elements not longer
 > representing "good" conceptual models of the in information in UML.
 > Because it provides an
 > explicit
 > representation of the global element and this makes the maintance of
 > the UML models much more difficult. So I'm agreeing furthermore the
 > only one "Venetian Blind" approach.

I'm really confused by this.  How can the CC work dictate a particular 
XML/XSD representation?



It seems to me that the main difficulty with the UML models is 
representing the entire expressiveness of the XSD without loss when 
there are global elements all over the place.  But is that a 
requirement?  What if the elements in a content model could be treated 
as properties unique (scoped) to the class they're in, which happen to 
be named in (what may appear, to the UML model, to be) a strange 
pattern?  Is there loss of extensibility if this is done?

(I hope to have some additional data from our JAXB team soon, as well...)

Thanks,

	Eve

Stuhec, Gunther wrote:
> Hello all,
> 
> do you have although a problem with the mail-server?
> I can't send the following message to the list server ubl@lists.oasis-open.org:
> 
> Hello all,
> 
> we in the core components group agreed last week that for leaf elements only data types are reusable and the BCCs as well as BIEs are not reusable. That means, it makes no sense if we're defining global declared elements for all BIEs and BCCs, because this will be used in aggregations only and this
> is the local element approach. And "data types" should be defined as global declared and reusable types. I hope, all are agree with this statement. 
> 
> I would like to say, this will be the "Garden of Venetian Blind" now (All data types are defined types, all BIEs and BCCs are defined as local defined elements, all ACC are defined as global declared types as well and all ABIEs could be defined as global declared elements
> 
> The question is now, should we define global declared elements for all aggregations (ABIEs and ACCs?). This means. As Dave Carlson mentioned that the "pseudo-classes" of global declared elements not longer representing "good" conceptual models of the in information in UML. Because it provides an
> explicit
> representation of the global element and this makes the maintance of the UML models much more difficult. So I'm agreeing furthermore the only one "Venetian Blind" approach.
> 
> Kind regards,
> 
> 	Gunther
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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