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

RE: painting types

• From: Jonathan Borden <jborden@m...>
• To: "Bullard, Claude L (Len)" <clbullar@i...>,"Simon St.Laurent" <simonstl@s...>, xml-dev@l...
• 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

• References:
  • RE: painting types
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: Re: What is an XPath API?
• Next by Date: PSVI
• Previous by thread: RE: painting types
• Next by thread: Moles and Holes (WAS RE: is that a fork in the road?)
• Index(es):
  • Date
  • Thread