ubl — archive

[Eve Maler]

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>