[
Lists Home |
Date Index |
Thread Index
]
>... that could be sort of dangerous, so much depends on what the business requirements
>are. The architecture for a site that has to do customized
>presentation for millions of users is probably very different than one
>that has to serve up similar content to many different device types in
>a corporate setting for 1000's of users.
What is a 'business requirement'? Presentation? That's so 90s. ;-)
How do you know when a "danger" is encountered? How do you know if
content is similar or dissimilar? If there are thousands of users,
when is a message appropriate or inappropriate?
What is the error/success collecting potential of a schema or a pipeline of such?
Where to errors/success messages go? Are there patterns to these exchanges?
Are these patterns evolving dynamically or statically? Are they stable?
A business architecture IS a pragmatic architecture. XML won because
it gives not a hoot about that. Objects thrive because they are political,
local, and care a great deal. If you mean to build an xml/xsl architecture,
you only have the bits on the wire. From the network's point of view,
that's all you need. From the application's point of view, that's just plumbing.
len
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
On 2/27/06, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> Would XML schemata be more powerful if they included a formal record of
> their failures in transactions?
>
> How would one represent that?
>
> Does that intersect with XSL that operates over the schema-scoped instances?
>
Huh ? (What does this have to do with the question at hand?)
|
