|
Chicken and egg. The impact of concern is the degree to
which legacy limits features and fielding. For example, I am neck deep in DTDs
because there is too little perceived value by the customer in retooling and
respecifying the GFI (Government Furnished Information) such as the stylesheets
and DTDs. Over time someone has to make a value case for the investment which
is why I bring up flaws I am seeing the products, the processes and the
follow-on costs as a result of lingering. Sometimes it takes a big impact such
as the problem of going to inexpensive but effective mobile devices to deliver
the information into hard to access locations where the infrastructure is poor,
non-existent or hostile. len From: Toby Considine
[mailto:tobyconsidine@gmail.com] On Behalf Of
Toby Considine The real issue, I
fear, is how many tools support it. Lots of folks would
use it as long as the object shim next to the data is generated by someone
else. Lots of folks would
use it as soon as their front end processors does. Early last Fall (the
last time I looked hard) there was minimal tooling, and less in the .NET space. tc "If something
is not worth doing, it`s not worth doing well" - Peter Drucker
From: Stephen D Green
[mailto:stephengreenubl@gmail.com] Use Case: Use of XML Schema 1.1 to strongly type a .NET DataSet i.e. Whether code which previously used XML Schema 1.0 for
strongly typed 'datasets' and supplemented that dataset with checks on co-constraints in handwritten code or in a combination of code and stored business
rule logic in a database or a file - whether that code would benefit from a
use of XML Schema 1.1 to associate the co-constraint business rules somehow with the strongly typed 'datasets'. Following on from Ken's message about the UBL use case, I must admit that in my use case above I tend to think the co-constraints are in
many real situations going to benefit from being easier to change than if
they were embedded in an XML Schema deep within the code. Putting such volatile things as co-constraint logic in such a relatively inaccessible place
as an XML schema used to support the typing of a DataSet or similar structure does seem sub-optimal for your average business application. ---- Stephen D Green On 14 August 2012 13:49, Stephen D Green <stephengreenubl@gmail.com>
wrote: Hi Roger As a C# / SQL Server developer by day and XML enthusiast by night I've
witnessed a great synergy between XML Schema 1.0 and the database where tons of code can
be circumvented with a schema-typed 'dataset' within the code and a corresponding
database set of tables in the database. The missing piece was a way to add co-constraints with a
similar reduction in the amount of code a so-armed web developer needed to write. At
the moment it seems a developer still spends a lot of time writing code for business rules
which actually amount to little more than coded co-constraints (co-constraints on the data in
tables and corresponding data structures/types). It would seem to me a good progression
toward less code and more agility to add co-constraints a la XML Schema 1.1 in .NET. In the
meantime I'll carry on coding all those business rule co-constraints myself or dumping them into
a table - keeps me in a job. ---- Stephen D Green On 14 August 2012 13:22, Costello, Roger L. <costello@mitre.org>
wrote: Hi Folks, |