[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: painting types
- From: Jonathan Borden <jborden@mediaone.net>
- To: "Bullard, Claude L (Len)" <clbullar@ingr.com>,"Simon St.Laurent" <simonstl@simonstl.com>, xml-dev@lists.xml.org
- Date: Tue, 06 Mar 2001 19:26:17 -0500
>
> >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*.
perhaps but this isn't as ominous as it appears. XML Schema provides for
types defined by a pattern, a regexp, so what has been the voodoo of a
'unsignedShortInt' that otherwise XML irrelevent non-text artifact of 16 bit
architectures -- can also be viewed as simply a character string that
matches a particular pattern. To turn this argument around, view an XML 1.0
Name as simply the simplest pattern -- it matches a literal string. Abstract
types are types that are assigned to types - sure its an extension but when
viewed as a regular expression, we are still in the text world we know and
love.
>
> >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?
testing for equality is the simplest, but posit a function "derivesFrom" as
in
"//*[derivesFrom(type(),xsd:unsignedInt)]"
>
> 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.
>
Another way would be to expose the infoset items as if something like an
"xsd:type" attribute were added to an element i.e.:
//*[@xsd:type='xsd:unsignedInt']
(the point being that all XPath implementations I know of already operate on
the parsed 'Infoset' whether you call that a series of SAX events, a DOM or
a JDOM).
I suppose they will create a new axis or something but the point is that I
can see a use for this that would be simple -- of course whether that's what
we will get remains a question.
-Jonathan