[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: painting types
- From: Jonathan Borden <email@example.com>
- To: "Bullard, Claude L (Len)" <firstname.lastname@example.org>,"Simon St.Laurent" <email@example.com>, firstname.lastname@example.org
- Date: Tue, 06 Mar 2001 18:08:22 -0500
> Ok. So please expand on "painting" so
> I get the whole picture.
> This seems to be settling down on types. XML
> schema does at least two things with types:
> 1. Allows one to use the 'primitive' types
> of the spec, roughly, the types that a relational
> programmer uses.
> 2. Allows one to create new types, such as
> the abstract types which are non-instantiable
> but name and enable one to choose among
> substitution groups.
> Of these, the first seems to be sharable among
> all languages and doesn't require a schema if
> they can be added inline, on the other hand,
> that is like archforms: a privileged set of
> names or attributes and that is just another
> kind of schema. The second group clearly requires schema.
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).
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)
3) In XML Schema the type of an element may similarly be inferred from its
name (modulo context dependencies).
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:
alternatively one can create a type chain akin to:
[someElt, rdf:type, XMLSchema#unsignedInt]
['12345', rdf:type, someElt]
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.
> 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
> 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
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.
> 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:
would simply select all the elements with type=xsd:unsignedInt.
One could construct *today* a query on an RDF store that would do the same
thing (of course converting xsd:unsignedInt into
The Open Healthcare Group