For the record: response on LC-102 microparsing: Suggestion: Micr oparsing support in XML Schema

The following response was sent on July 12, 2000.  The commentor responded
privately on August 17, 2000, and the response is attached at the end of this
note.  A subsequent message to the commentor was sent on October 5, 2000 and
is in the xml-schema-comments archive.

Message-ID: <472E220BA79DD11186340060B06B38D9033ACD6F@tpantmail1.ssr.hp.com>
From: David Ezell 
Date: Wed, 12 Jul 2000 18:22:42 -0400
Subject: LC-102 microparsing: Suggestion: Microparsing support in XML Sche
ma

On Wed, 10 May 2000 09:47:27 +0200 Anders W. Tell wrote:

>Problem:
>
>A common phenomena which now and then surfaces in the markup 
>world is the occurrence of what some authors call "Micro-parsing". 
>This is the situation when Schema writers define that a XML 
>attribute should contain structured information and therefore 
>creates a need for customized parsers, hence the above term. 
>
>Two examples are 
>
>XPath expression in XSL: match="/cars/car[@name='volvo']"
>Path in SVG: <path d="M 100 100 L 140 100 L 120 140 z"/>

Dear Mr. Tell:

First, thanks very much for your very conscientiously presented
ideas.  I believe that they have merit.  However, introducing
these ideas into XML Schema Version 1 might be quite complex and
could delay the introduction of the rec considerably.  

For quite some time, the WG considered a similar use case involving 
units of measure embedded in a string type.  The WG finally decided
"not in Version 1" on that use case because the first version
of Schemas should leave complex  (i.e. compound) types to be denoted 
by XML markup.  For similar reasons, the WG stopped short of defining
a special type for XPaths.

Hopefully having achieved that goal (complex type semantics) in 
version 1, many in the WG would like to revisit what have been 
dubbed "complex simple types" like those in your examples.  During
that revisitation, I think that your ideas will be quite valuable.

My suggestion is that for version 1, the semantics of both XPath and
the SVG path EII are the responsibility of those processors which
use them, e.g. XSLT, etc.  Hopefully this will not be a great
burden in the meantime, and we can begin work on version 2.

Please let me hear from you as to whether you consider this propos-
ition acceptable.

Sincerely,
David Ezell, HP
for the XML Schema WG

===================
response from Anders Tell to the above message via private email August 17, 2000
===================
David Ezell wrote:

> On Wed, 10 May 2000 09:47:27 +0200 Anders W. Tell wrote:
>
> >Problem:
> >
> >A common phenomena which now and then surfaces in the markup
> >world is the occurrence of what some authors call "Micro-parsing".
> >This is the situation when Schema writers define that a XML
> >attribute should contain structured information and therefore
> >creates a need for customized parsers, hence the above term.
> >
> >Two examples are
> >
> >XPath expression in XSL: match="/cars/car[@name='volvo']"
> >Path in SVG: <path d="M 100 100 L 140 100 L 120 140 z"/>
>
> Dear Mr. Tell:
>
> First, thanks very much for your very conscientiously presented
> ideas.  I believe that they have merit.  However, introducing
> these ideas into XML Schema Version 1 might be quite complex and
> could delay the introduction of the rec considerably.
>
> For quite some time, the WG considered a similar use case involving
> units of measure embedded in a string type.  The WG finally decided
> "not in Version 1" on that use case because the first version
> of Schemas should leave complex  (i.e. compound) types to be denoted
> by XML markup.  For similar reasons, the WG stopped short of defining
> a special type for XPaths.
>
> Hopefully having achieved that goal (complex type semantics) in
> version 1, many in the WG would like to revisit what have been
> dubbed "complex simple types" like those in your examples.  During
> that revisitation, I think that your ideas will be quite valuable.
>
> My suggestion is that for version 1, the semantics of both XPath and
> the SVG path EII are the responsibility of those processors which
> use them, e.g. XSLT, etc.  Hopefully this will not be a great
> burden in the meantime, and we can begin work on version 2.
>
> Please let me hear from you as to whether you consider this proposition
> acceptable.
>
> Sincerely,
> David Ezell, HP
> for the XML Schema WG

Im sorry I have not been able to get back to you on this issue before but

I have been on a long holiday and got back this tuesday.

I think there are two issues here, the first one is the mechanism of
associating
equivalent XML schema component and a parser identifier with simpleTypes
the second is what should the schema component be for xpaths, SVG paths
etc. be.
The first one could easily fit into version 1 and the second in version 2

The term "complex simple types" does not really cover what I want to
accomplish,
Im just trying to define equivalence in terms of encodings, without any
type semantics.
So shorthand/readable encodings can be unwrapped into xml.

I also have found another use case for microparsing, or parsable
encodings as I call them,
which is when someone decides to create URL, URI, ID, IDREF according to
some
principles/rules, by associating an equivalent XML schema component and a
parser identifier
all schema aware applications can do lazy binding between URL, URI, ID,
IDREF and a
equivalent XML fragment.

My first  recommendation is to try to get issue 1 into first spec. and
work on mapping
xpath and svg path  in version 2. However I have already started to use
annotations for
this purpose so Im quite happy using this workaround.


You mentioned that the type-system (complex type semantics) is one or the
more
important goals. I have recently come to the conclusiong that the first
version of XML schema
should not include a type-system, it should instead focus on how to
define,combine, package, etc.
attributes, elements and xml fragment. The currently type system is too
"simple" and should instead
be should layered ontop xml schema. The equivalenceClass concept is also
too simple.
So I propose a two layer solution where layer one contains xml
"combination" rules and layer two
contains type and substitution semantics.
Just look at the OMG Corba typesystem which XML schema cannot handle with
out
being extended by annotations.

Regards
/anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB            /
/  Anders W. Tell                     /
/ WWW:  <http://www.toolsmiths.se>    /
/ XIOP: <http://xiop.sourceforge.net> /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Received on Monday, 9 October 2000 08:59:34 UTC