RE: painting types

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

From: Jonathan Borden [mailto:jborden@mediaone.net]

>Not exactly (IMHO)

>1) In XML 1.0 the type of an element "element type" is defined by the name
>of the element (see http://www.w3.org/TR/REC-xml.html#dt-eldecl).

Ok.  That is so.  That is why it is called an element type declaration. 
It doesn't do much more than reserve a string in a scoped context, but that 
is what it says.  Sort of a compiler widget, a symbol.

>2) In RDF the type of a node is defined by the URI which represents the
>QName of the node (see typedNode production), and hence this idea of an
>element type being defined by its name is carried forward (essentially a
>namespaced/prefix indenpendent version of the element name)

A map of the symbol widget.  Ok, trickery to enable a symbol table 
with multiple parents look like it has a root.

>3) In XML Schema the type of an element may similarly be inferred from its
>name (modulo context dependencies).

That gets dicey.  Type is an overloaded term in XML Schema.  Integer is a 
type too.  An abstract type is assignable.  Type just diverged
*meaningfully*.

One can view the directed labeled graph which represents the RDF
interpretation of an XML document (see
http://www.openhealth.org/RDF/rdf_Syntax_and_Names.htm) as a pruned grove or
infoset where things like the differences between attribute and element
values, or element order, etc. are not important nor maintained in the RDF
'infoset' -- but realize that the RDF graph *is* very much a type of grove.

>In RDF, type information is assigned via an arc from the node to the type
>having an arcname of "rdf:type" -- pretty simple. This is identical to:

> <someElt rdf:type="http://www.w3.org/2000/10/XMLSchema#unsignedInt"
> >34567</someElt>

Ok.  "RDFs do it. Schemas do it.  Even plans in grovey trees do it. 
Let's do it.  Let's type in nodes..."  (sorry, late in the day).

>So in my view, the process of interpreting an XML Document as RDF results
in
>the assignment of type information. Assume an RDF processor operates on a
>'raw' XML infoset, strips out unnessary information items and assigns type
>information. XML Schema is yet another application which assigns type
>information to a 'raw' XML infoset.

I'm with you so far and not sure what the problem is other than XML Schema 
does more with the term "type".  However, the notion that languages other 
than XML Schema can make an infoSet contribution doesn't seem controversial.
Is it? 
It is how other languages have to interact with these contributions if at
all.

>> 1.  The first issue as I understand it
>> is that without an infoSet extensive enough
>> to be considered a complete data model, there
>> isn't enough information to hyperlink reliably
>> or perform other common operations (what APIs
>> spec by interface).
>>
>> That was the nut of the groves tree as well.

>XSet *is* a full XML property set (or grove), but the Infoset does allow
>addressing anything that XPath/XPointer can address so I'm not sure that's
>the problem.

Right.  It is the issue.  What is the base InfoSet, or commonality among 
the applicaton languages that provides the common data model?  XSet is 
complete.  InfoSet is common.  How does a language 
denote its infoSet contribution such that other languages can use it? 

What makes a PnVI public or discoverable?

>
>> 2.  The second issue is that if alternative
>> schema means are used, the data model still
>> has to be accounted for by XPath and XSLT.
>> The grove guys get another point for the
>> grove plans idea.  We need something of that
>> sort and that is what Henry says in his
>> presentation.

>agreed. start with the full grove (XSet provides this), prune to either the
>Infoset, PSVI, or RDF Model or to whatever else you care about.

Agreed.

>> What precisely happens in XSLT and XPath without
>> schemas?  What precisely happens with schemas?
>> Its all about properties that are there or not
>> there in a data model.  If there are alternatives
>> to schemas, how does XSLT and XPath cope without
>> knowing in advance what post-process added to
>> the nodes in the data model?

>I can't say for sure what XPath 2.0 will look like, but if I were doing it
I
>would create a function 'type()' which returns the qname of the type of the
>element in question the xpath:

>"//*[type()='xsd:unsignedIt']

>would simply select all the elements with type=xsd:unsignedInt.

Ok.  Does that handle problems such as 'abstract types' or are these 
just an overloading of the term and do not make infoSet contributions?

I'm looking for the "complexity" that worries people.  You seem to be 
saying a function that returns the infoSet contributions (sort of the 
sonOfIUnknown) is sufficient.

Thanks, Jonathan.  Illuminating.

len