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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: infinite depth to namespaces



Simon sez:
> Should be a beautiful world for some folks, but I don't think that
> normative syntax is going to help too awfully much with keeping the
> Infoset folks from painting XML into something far grander 
> than syntax.
> The developers writing the business logic are eventually going to get
> aggravated about writing code that duplicated previous checks, and I
> suspect they'll respond by insisting that schemas start 
> supporting more
> business logic.  (That's been happening for a while, it seems.)

I think even database afficionados would argue for the separation of
volatile "business logic" (which directs the processing of data) from the
more stolid type constraints that schemas provide. Admittedly, the line is a
little fuzzy, but it's there.

In databases, triggers and stored procedures have there place, but people
soon found out that pernicious centralized process control caused all sorts
of problems when requirements changed or diverged. What I think you'll soon
see is a desire to standardize the loose coupling of schema constraints with
business logic, such as adding protocols to appInfo annotations. Perhaps not
a pretty or even good solution, but a makeshift one that will do for awhile.
Cleaner couplings would have litte, if any, impact on XML (one would hope).

In the end, I think XML and XML types will be isolated in the data layer
along with semi-automated storage mechansisms. On top of that would be glue
code for loosely couple business logic, which in turn has application logic
resting on top of that. That's a little utopian but grossly represents how
data-intensive systems are architected now.

You document people will get along just fine without worrying your pretty
little heads about all that...

-- Jeff