Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] RE: Keep business-process-specific data separate?

From: "Cox, Bruce" <Bruce.Cox@-----.--->
To: "Peter Hunsberger" <peter.hunsberger@-----.--->, "Keith Hassen"
Date: 2/3/2009 1:05:00 AM
If I understand OED correctly, "animals" is a generalization (generic,
genre).  A name for a collection of objects with a common property.

Abstract is both a verb and an adjective.  I don't think the verb
applies here, as someone else suggested.  That I appear to abstract a
category by inspection of some collection of instances doesn't make the
category itself abstract, merely derivative.  Animal as distinct from
vegetable or mineral is, I think, mostly about a bunch of properties by
which we distinguish things in the real world.  Yes, it gets messy along
the edges, which is one of those things you want to avoid in your
schemas.  That's why Congress passed a law declaring tomatoes to be
vegetables, not fruit, even though they are fruit from a strictly
biological perspective.  When designing a schema, pay attention to the
edge cases, they will cost you the most.  We've spent ten times more
hours discussing markup for deceased (and other types of non-signing)
inventors than we did for the living.

The more generic your schema, the worse the edge cases, I expect.  In
the case of an abstract schema, I would expect there to be NO edge
cases, since everything will behave "ideally", like electrons and
photons in those films we saw in high school back in 1965.  I mean,
there are no edge cases for the Pythagorean theorem (at least not in
Euclidean geometry), are there?

Bruce B Cox
Manager, Standards Development Division
USPTO/OCIO/SDMG
571-272-9004


-----Original Message-----
From: Peter Hunsberger [mailto:peter.hunsberger@g...] 
Sent: Monday, February 02, 2009 4:40 PM
To: Keith Hassen
Cc: xml-dev@l...
Subject: Re: [xml-dev] RE: Keep business-process-specific data separate?

On Mon, Feb 2, 2009 at 2:54 PM, Keith Hassen <keith.hassen@g...>
wrote:
> Since 0.02 is being thrown around ... I'll give it a stab ...
>
> Wouldn't an abstract description be a definition that permits you to
perform
> *deduction* in order to derive further "solutions"?  In contrast, a
generic
> description is simply a way to describe a certain class of items
without an
> inherent mechanism to logically introduce new elements into that
class? (ie.
> no deduction can be formed based on the generic description)
>

Forgot to reply to all (sigh).  At first this seems useful, and so far
it get's my vote. However, upon pondering this a bit more I've now got
to ask; is the class of "animals" an abstraction or a generalization?

-- 
Peter Hunsberger


_______________________________________________________________________

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@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent