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

["Eve L. Maler" <eve.maler@sun.com>]

I should explain a bit more...  I'm absolutely open to the possibility 
of learning that there's something about the OO connection that makes 
one or another XSD approach more viable or optimal, and if such features 
are weighed against the benefits of referenceable (global) element 
declarations and found more important by the group, fine.

But, just as an example, in my work on the SAML schemas, I haven't heard 
any feedback from my JAXB colleagues that the choice of global vs. local 
makes much of a difference in the results of pushbutton class 
generation.  (On the other hand, I have heard from them on things like 
wildcards and substitution groups vs. choice groups, none of which seems 
to be an issue here.)  I should have thought to check with them before 
now, and will do so and report what I learn.

I have to admit that the discussion we've been having about global vs. 
local is making me think that I would have done SAML differently; 
currently all the elements there are global.  What I might have done 
instead is make only the elements we deem reusable (assertions, 
requests, and responses mainly) global, with the rest being local and 
qualified; you can currently reuse an element in the middle of SAML's 
model, but doing so has no standardized semantics and is forbidden in prose.

However, since UBL is supposed to be a reusable library of well-defined 
semantics, any global element bound to a type has at least that much 
meaning, and could be useful for customizers in building new document 
types.  (Do we need to better validate this use case?)  But if OO 
practice doesn't interfere with it, then I would still be on the side of 
enabling element-level reuse.

	Eve

Dan Vint wrote:
> I'll jump in here as well and agree with Eve and Mark. I'm new to this 
> process, but it seems to me we should be making "proper" XML. Technology 
> changes and next week UML might not be the way to model things and FOO 
> is the latest methodology, would we change the design/process to then be 
> more conformant with that methodology? Why shouldn't we choose ER 
> diagrams as the better modeling environment and make our XML look like 
> tables?
> 
> I have some trouble with the idea of trying to force XML into 
> tools/methods that aren't designed to be used with it or for it. There 
> are things in UML/OO that I can do that I can't in XML, and likewise 
> things and methods in XML that don't map well to UML/OO.
> 
> Until someone comes up with a truly universal modeling language that can 
> handle OO, relational databases, XML, etc. without "forcing the process 
> or method" I don't see how you can choose something that doesn't work 
> completely with the target implementation and say it should conform to 
> the other. Maybe OO languages will morph to something that better fits 
> the XML world in the near future.
> 
> This is another opinion from a non--OO comfortable developer.
> 
> ..dan
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>