Lists Home |
Date 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.
From: Peter Hunsberger [mailto:email@example.com]
On 2/27/06, Bullard, Claude L (Len) <firstname.lastname@example.org> 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?)