[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: fundamental facets - inquiry from the XMLSchemaWorking Gro

• To: Eric van der Vlist <vdv@d...>
• Subject: RE: fundamental facets - inquiry from the XMLSchemaWorking Group
• From: Rick Marshall <rjm@z...>
• Date: Sat, 11 Oct 2003 11:16:08 +1000
• Cc: xml-dev@l...
• In-reply-to: <1065803799.748.55.camel@delleric>
• Organization: Zenucom Pty Limited
• References: <830178CE7378FC40BC6F1DDADCFDD1D1D51621@R...> <1065803799.748.55.camel@delleric>
• Reply-to: rjm@z...

i could be way off here - flames accepted, but it seems to me (and it's
certainly my experience) that to get to the next level of anything we
have to be better at all the ontology stuff.

datatypes as we use them aren't very good. the zip code example earlier
is a good example - looks like a number, but isn't and the concept of
2002 - 1075 when they are zip codes (or post codes etc) is meaningless
and we have to be able to express that. adding dates is meaningless (but
subtracting dates is meaningful), but adding days to a date is
meaningful. and dates aren't numbers either.

so you make a database "richer" by adding new domains. whether by
standards decree or by implementor extension is worth the debate (i
favour the former for interoperability reasons) but the basic idea is we
should look at the things we're representing, decide on domains, the
rules of the domains and then they can be implemented.

then we have something.

it's a bit long winded, but we need to say something like:

<domains>
<domain name="integer">
	<operator name="+" type="binary" result="integer">
		<operand domain="integer">
			<valid>integer</valid>
			</operand>
		</operator>
	<operator name="-" type="binary" result="integer">
		<operand domain="integer">
			<valid>integer</valid>
			</operand>
		</operator>
	</domain>

<domain name="date">
	<operator name="+" type="binary" result="date">
		<operand domain="date">
			<valid>integer</valid>
			</operand>
		<operand domain="integer">
			<valid>date</valid>
			</operand>
		</operator>
	<operator name="-" type="binary" result="integer">
		<operand domain="date">
			<valid>date</valid>
			</operand>
		</operator>
	<operator name="-" type="binary" result="date">
		<operand domain="date">
			<valid>integer</valid>
			</operand>
		</operator.
	</domain>
	</domains>

etc

we might even allow for base laws such saying a domain is group, field,
set etc to allow pre defined rules, and similarly expressed validations
- although i think i'm on record here as saying simple validations are
imho of limited value. validations should be expressions between
attributes - much more important.

this could be easily parsed as well.

rick

On Sat, 2003-10-11 at 02:36, Eric van der Vlist wrote:
> On Fri, 2003-10-10 at 18:27, Dare Obasanjo wrote:
> > All of these problems don't matter as much if all you are designing is a validation language. They mainly become problematic when you want to perform operations on these types either in a programming or query language. 
> 
> Really?
> 
> How do you constrain a date in the Japanese calendar or a complex number
> without having either hardcoded these types in your type system or
> defined a system which lets you define new primitive datatypes?
> 
> Eric

• Follow-Ups:
  • Re: fundamental facets - inquiry from the XML SchemaWorking Group
    • From: Liam Quin <liam@w...>

• References:
  • RE: fundamental facets - inquiry from the XML SchemaWorking Group
    • From: "Dare Obasanjo" <dareo@m...>
  • RE: fundamental facets - inquiry from the XMLSchemaWorking Group
    • From: Eric van der Vlist <vdv@d...>

• Prev by Date: RE: Beyond Ontologies
• Next by Date: Re: fundamental facets - inquiry from the XML SchemaWorking Group
• Previous by thread: RE: fundamental facets - inquiry from the XMLSchemaWorking Group
• Next by thread: Re: fundamental facets - inquiry from the XML SchemaWorking Group
• Index(es):
  • Date
  • Thread