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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: Fwd: [xml-dev] Not using mixed content? Then don't use XML

Agree. The problem comes first. And: expect change.

If you strive for Quality Without A Name (Christopher Alexander allusion), you cannot just copy any old cookbook pattern. You have to get involved and understand what is going on; there are no shortcuts to qualified design decisions.

Once you understand what's in play, what people involved are up to, you will often find that a composition of old cookbook patterns describe the situation well. And sometimes you will have the joy of discovering a new situation, a new pattern.

Obviously, our understanding of what is going on will be limited and incomplete. As an engineer, it is my profession to make informed decisions given noisy and incomplete information, c'est la vie. It is also my profession to do myself and my colleagues the favour to name assumptions, to offer handles to the design decisions made, to present models of the design: to expect change.

Unnamed assumptions create a global state that makes change risky: there is no way to explore the impact of a change except in full scale. Also, it gets costly to identify bottlenecks and boat anchors, because you have to benchmark the complete process rather named components. You get stuck with blackboxes and implied workflow patterns that are no longer relevant. Like, "Articles are referred to by issue number and page number", distributed all over work flow, data models, and code. I'm sure a lot of you docheads recognize this situation. Years ago, digital publishing used to piggyback on paged media. Today, having paginated media as a prerequisite to digital publishing is a royal PITA. And, if identifiers in your workflow are implicitly depending on paged media, the pain is a lot worse than it need be. If you cannot abstract from previous assumptions, if you cannot talk about work, expression, manifestation, and item, you're stuck with whatever chance brought you. Schema are ways to make your assumptions visible and subject to change.

If in doubt, focus on the customer. If you don't know your customer, you are in trouble.

On Sun, Apr 7, 2013 at 3:24 AM, Simon St.Laurent <simonstl@simonstl.com> wrote:
On 4/6/13 5:46 AM, Timothy W. Cook wrote:
My impression is that a VERY large percentage of the contributors here
are involved in text management; not application development.

The document-data divide is important in many conversations, but I don't think it applies to this one particularly.

My point, at least, is that schema-first or schema-centric design, any situation in which the schema is considered more than a snapshot of current conversational practice, is actively harmful.

It doesn't matter whether than schema uses a DTD, XML Schema, RELAX NG, Examplotron, or even some other form.  I think XML Schema and the toolset surrounding it encourage more serious problems to develop, problems we often ignore by calling them features.  However, these issues are hardly unique to XML Schema or to given fields of markup application.

I'll be writing more on this soon, and hope to have a more coherent telling of the story than I've had so far.

 From a developer point of view I love the additions to XML Schema 1.1.
   Now I can use XML, stay in one family of tools and perform
computational processing across data.  But until 1.1, XML was just a
pain to move around, parse the data back out and do something

So, before you go bashing on XML Schema, just admit that it might no
be useful for you.  That doesn't mean it is bad or not useful to

Unfortunately, when an epidemic is raging, the behavior of everyone around us matters.

Simon St.Laurent


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS