OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [humanmarkup-comment] [measurment] new version of type toolkit



This was probably going to the list, so I have kept the whole message 
and included my comments inline.

cognite@zianet.com wrote:
> interesting stuff.  Types in general are not obvious in the real world,
> though readily assignable arbitrarily in definable worlds.  These, of
> course, are clearly labeled as  W3Cese. ;-)

Yes, W3C is the authority for those simple type definitions I have 
imported. Although I am no big fun of W3C XML Schema, it's what I use 
90% of the time because our clients want it, because they know what to 
do with it (or at least their software does).

Although W3Cese, those types are a bridge between markup and typed 
languages or databases. Note that RDF itself will not interpret or 
validate instances of a type; it will just pass a value of a certain 
type to another application. The RDF type hierarchy serves as a 
description of the relationships between the types, something you never 
know what use may bring. One example may be type fallback. For example, 
if an application can't figure out what positiveInteger is, it will 
interpret it as an integer.



 >  Labelling like that might apply
> for whatever vocabs we pick up as given dialects' descriptors, perhaps.
> Something to keep in mind in extending and integrating this with our other
> stuff..


Yup.


> In the earlier version
> At 03:52 PM 23-09-2002 +0300,  Manos Batsis wrote:
> 
> - about Isaviz.  Nice justification for working on an exciting thing set
> aside earlier!

Isaviz actually helped me in spoting errors, while it gives a nice view 
of the RDF graph.


> - about the not-to-be-lost-in-the-shuffle canonical  graphic representation
> of the W3C types at 
>         http://www.w3.org/TR/2001/PR-xmlschema-2-20010330/type-hierarchy.jpg
> If we use this kind of graphic, let's use colors that are more Different,
> like blue  and green, not blue1 and blue2.  
> 
> Judging from Manos' module of their "built-in primitive types" and "built-in
> derived types", "derived" is supposed to mean exactly... what?  What are the
> rules for their "complex types" as opposed to these, if there's an easy way
> to say.

<anti-pedantic>
Well, those characterizations are mostly conseptual, although with 
technical grounding. Primitives are what is commonly accepted as 
primitives in programming languages.

XML Schema anticipates two derivation methods on simple types, 
derivation by restriction and derivation by list.

A type that is derived by restriction, is a subset of it's parent. More 
specifically, it's value space [1] is a subset of the parent type's 
value space. So, integer has a value space of al integer numbers, but 
positive integer has a value space composed of positive integers only.

A typed that is derived by list, is a set that can have only members of 
the parent type.

Both derivation methods are conseptual utilities for validation of value 
spaces.
</anti-pedantic>

> Is there an equivalent EBNF?  That might make it more clear. 

I'm not aware of one. In general, you may want to study [2]. People that 
may want to extend and build their own simple types will be interested 
in the regular expressions that can be interpreted by W3C XML Schema.

[1] http://www.w3.org/TR/xmlschema-2/#dt-value-space
[2] http://www.w3.org/TR/xmlschema-2/


Manos



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC