From: P A Hill & E V Goodall (goodhill_at_xmission.com)
Date: Mon Oct 21 2002 - 17:06:32 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id E3DF515A5A for <cavexml-outgoing_at_ethz.ch>; Mon, 21 Oct 2002 17:25:56 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id BC344159F1; Mon, 21 Oct 2002 17:25:53 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id A682F15A5A for <cavexml-loopcheck_at_ethz.ch>; Mon, 21 Oct 2002 17:25:52 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 7742A159D6; Mon, 21 Oct 2002 17:25:49 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 2352115A5A for <cavexml_at_cartography.ch>; Mon, 21 Oct 2002 17:25:49 +0200 (CEST) Received: from mgr4.xmission.com (mgr4.xmission.com [198.60.22.204]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 8DD7614ACF for <cavexml_at_cartography.ch>; Mon, 21 Oct 2002 17:25:45 +0200 (CEST) Received: from [198.60.22.200] (helo=mail.xmission.com) by mgr4.xmission.com with esmtp (Exim 3.35 #1) id 183e8s-0003vG-00 for cavexml_at_cartography.ch; Mon, 21 Oct 2002 09:06:54 -0600 Received: from goodhill.dsl.xmission.com ([198.60.114.17] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.22 #1) id 183e8s-0001y7-00 for cavexml_at_cartography.ch; Mon, 21 Oct 2002 09:06:54 -0600 Message-ID: <3DB417F8.2060907@xmission.com> Date: Mon, 21 Oct 2002 09:06:32 -0600 From: P A Hill & E V Goodall <goodhill_at_xmission.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en To: cavexml_at_cartography.ch Subject: Re: Other Definitions - Raw vs Field References: <20021020134116.4509D7E98_at_karmail.ethz.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
Richard Knapp wrote:
> I don't see
> how a sketch or image can make the "jump" from Field data to Raw data if
> the given constraints are to be maintained.
A sketch doesn't make it to Raw. Did I say that? If so, I didn't mean to.
How any data goes from any state to another is up to the software doing it,
any format invented here or anywhere else only provides a place to put such
data if and when the data is generated. But we haven't gotten there yet,
we were just trying to define what possible states a piece of data might be in.
> Okay. So how does a scanned page become character-based machine-readable
> (CBMR)? or is CBMR the same as binary?
How is does it become now? Someone looks at the "field" data and types the
actual numeric values into some application. Defining the difference
between "field" and "raw" doesn't change what can or can not be done.
CBMR same as binary? What do you want to stick with this particular
interpretation? I suggested "text based" as a better way to differentiate.
I think the use of the term is an improvement, because it avoid this
attempt to shoehorn an image into the category we are calling "raw".
We could further clarify by describing where images do fit. There no rule
that says we can't define by example.
A few messages back you asked:
>>>The paper sketch is Field data, so what is a scanned sketch?
A scanned sketch is still "raw" data? There are not enough categories here
to call it anything else. I don't think there needs to be any more
categories. Others have already pointed out that some software will not
every deal with all of these forms.
On the other hand, to play with other theoretical forms of data, which is
probably of limited productivity, if someone generates some type of
interesting digitized form of walls, we might discuss the "field" version
of the walls (on the image or in the book), the "raw" version (a digitized
line) and even some theoretical "leg" version of the data (tied to some
coherent segment of passage). The definitions do seem to work when applied
to this thought problem.
> XML does not embed images. It provides a link to the image. The only way
> to embed an image in XML would be to use the proposed Binary XML. From > the
I'm all for using standards, so I'd encourage the use of whatever new
schemes for this come along, but I am certainly within the bounds of
existing XML to define some tag and then claim to the users for that tag,
that the CDATA which is contained within happens to be an image organized
in some way.
Have I violated what you see as the terms as they are defined? How should
they be different?
-Paul
This archive was generated by hypermail 2b30 : Thu Oct 31 2002 - 23:00:00 CET