Lists Home |
Date Index |
- To: 'Mike Champion' <firstname.lastname@example.org>, email@example.com
- Subject: RE: [xml-dev] Re: XML and Complex Systems ((was Re: [xml-dev] Re: An Architecture for Limericks) was RE: RE: RE: [xml-dev] XML=WAP? And DOA?))
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- Date: Mon, 14 Jan 2002 15:11:48 -0600
Now is that pattern emergent or simply "discoverable"?
I don't think the term matters. The point is, a real
signal source is examined, patterns are detected,
named, and documented. In the case of a DTD or Schema,
it is a computable document that serves as a means to
detect the pattern or deviations from it. All the
DTD or Schema is is a control. Now one inquires of
the example, is it sufficiently representative of
what I expect to apply the control cost-effectively
(for some range and type of cost) to? That is, did I
find all/sufficient hidden couplers that over time will
perturb the data patterns? The question of the DTD or
Schema and should I use it is simply, does it do a
job that I can afford it to do better than any
alternative I can afford.
Think of the job SETI does. Given the universe,
can you conceive of universal schemata that would
automatically detect a well-formed message from an
alien culture? If you scope that "in terms of our
own understanding", you can and it might look distressingly
like the "limerick" designs: it can't detect meaning,
but it can find patterns that nature does not produce.
Is that useful? If the only fact you need to establish
is that it is an artficial signal, yes. If you need
more meaningful communication, you may be out of luck
unless you can arrange an F2F with a civilization you
cannot name and can only locate with regard to a timespace
that is larger than you or your heirs life spans.
That's the worst case, AFAIK.
From: Mike Champion [mailto:email@example.com]
1/14/2002 3:28:56 PM, Nicolas LEHUEN
> By restricting this range, you'll define an operational
> schema, and implicit or explicit schema that is used to
> process incoming data. This schema will certainly
> contain "holes", <xsd:all> patterns, or even some more
>"fuzzy" patterns (such as 'foo//bar' in XPath, for which I
> don't know if there is an equivalent in XML Schema or RELAX
> NG), but it will be a schema nonetheless.
That's an awfully good point! A "pattern" is indeed a
"schema," albeit one at a more abstract level than XML schema
languages can probably handle.
Likewise your points about "self-documenting" tags; there is
some implicit reference to a schema or other shared
understanding, and whenever this can be made explicit --
with namespaces, schema, schema adjuncts, etc. -- it is
probably best to do so.