In the majority of cases, the schema should win because it drives
machines and people adapt better. However, as the designer
implementing it and if there is no one to ask, I implement the one
that makes the most sense as long as I control the schema. If I don't
I either implement the schema or I send out error notices saying "the
schema doesn't make sense; I adjusted it as follows...".
I am continually surprised by the lack of understanding among those
who write contracts, procurements, proposals etc. about the issues of
citing schemas they themselves have never looked at or understand.
(XML illiteracy is a serious issue in procurement circles.)
Real discussion:
XML Implementer: "I know you are several months into building your MS
Word templates and spreadsheets, but you S1000D infoCodes aren't valid."
Document Designer and Big Poobah: "Those codes were selected intelligently."
XI: "Did you read the schema pattern facets?"
DD&BP: "The WHAT? I DON'T HAVE TO KNOW THAT TO DO MY JOB. THOSE CODES WERE
SELECTED INTELLIGENTLY!!! .... so what should we do?"
XI: "The only impact at this time is when we open the module to
format it, the XML validator will issue error messages then ask you if
you want coffee with that. Otherwise, it will keep working. So we
can ignore the errors for now. Or I can adjust the schema and the
errors will stop."
DD&P: "Then fix the schema."
XI: "I will if you say so but the first time you have to deliver the
XML instead of making PDFs, the receiving organization will kick them
back for being non-conforming. And over time as changes are made by
the folks designing
the schema record of authority, your files will drift further out of
compliance. Worse, those codes are part of the overall set of
identifiers to which references are made. If you wait and you are
asked to bring it up to spec, you'll have a lot of work to do. Just
sayin'...."
DD&P: "You're scaring me with this stuff. In the out years, you are
too expensive to keep around. I'll hire a college kid who knows a
little XML to come do this. Are you saying I won't be able to do that?"
And your answer to the last question should be?
XI: "Don't worry. Just do that."
You see, Dunning-Krueger is real and can only be cured by repeated
hits on the head with a blunt object.
It's a messy world and gets messier the longer one ignores the rules.
Creativity and pipelines of data that has to be both correct by
construction and in compliance to enable decoupled processes do not
congeal happily or cheaply.
len
Quoting Michael Sokolov <>:
> On 12/20/13 5:34 AM, Michael Kay wrote:
>>> One resolution is to write into the text "if there are any
>>> conflicts, the schema wins". I don't think it's helpful to write
>>> into the text "if there are any conflicts with the schema, the
>>> text wins," since schema users will just ignore that, and I don't
>>> know how to write into the schema, "if there are any conflicts
>>> with the text, the text wins," although that might be what is
>>> wanted.
>>>
>> It doesn't matter what you write down, it depends on who wins when
>> you start fighting over it.
>>
>> It comes back to the question I often ask about constraints: what
>> happens when your man in Egypt employs a 14-year-old tea-boy and
>> the database (or the company process manual) says he can't? Does
>> the tea-boy get sacked, or not? I'm sure the answer is likely to
>> vary from one company to another, and probably depends on
>> personalities. In most organisations I've come across, the tea-boy
>> stays, but off the official payroll, so everyone is happy.
>>
>> In XML terms, the schema wins, the tea-boy doesn't appear in the
>> instance documents, or if he does, he appears with a falsified age.
>> But he's still there, making tea.
>>
>> Michael Kay
>> Saxonica
>>
> Yes, organizations practice a kind of constructive self-deception in
> which everyone goes away thinking they've won, while holding
> different views.
>
> -Mike
>
