Re: [xml-dev] Is Schematron (using XPath 2.0) functionally a superset of

[Michele Vivoda <idmichele@yahoo.it>]

--- Rick Jelliffe <rjelliffe@allette.com.au> ha
scritto:

> On Sat, 2007-11-10 at 11:58 +0100, Michele Vivoda
> wrote:
> > Hi,
> > 
> > I use the schema also for its data-description 
> > features: to know which element/attrs are allowed,
> > datatype etc, before validation, 
> > to _produce_ instances, that then I will validate.
> 
> > I think that it would be hard to 
> > get the same description from a list of xpaths,
> > or at least I wouldn't know where to start.
> 
> Where to start? Well, forget grammars and learn
> XPaths! 

Wow, thanks for the long response.

Just as a personal background introduction, 
I do like XPath and XSLT which I have been using for
long time. 
I am not a fan of w3c xml schema, but lately I am
starting to surrend, 
dropping my "futile resistance". I haven't learned
XPath2 yet.

My doubts in the assertions approach are probably due
also to my 
object-databinding background, as opposed to a
documental one.

> 
> More seriously, apart from the issue of expressive
> power (which
> Schematron w XSLT2 wins AFAICS) I would never
> dispute that  some things
> are easier to express in Schematron and some things
> are easier to
> express in XSD; indeed, some things are easier to
> express using XPaths
> and some things are easier to express using
> grammars. However, you set
> yourself a hard task if you are defending XSD
> because of its
> user-friendliness :-)

For sure, it is a provocation ;-) 

Anyway my concerns are not so much in the "express"
side but 
in the "understand what is expressed" side.

> 
> Why is it particularly harder to write a flat set of
> declarations
> 
> <xsh:pattern>
> 	<sch:rule context="AAA">
> 		...
> 	</sch:rule>
> 
> 	<sch:rule context="AAA/BBB">
> 		...
> 	</sch:rule>
> </sch:pattern>
> 
> 
> than a nested set?
> 
>  <xsd:element name="AAA">
> 	<xsd:complexType>
> 		<xsd:sequence>
> 			<xsd:element name="BBB">
> 				...
> 			</xsd:element>
> 			...
> 		</xsd:sequence>
> 	</xsd:complexType>
>  </xsd:element>

I think that there isn't any major difference when you
"write", while what 
is much harder for an application  is understanding
what is written, 
because "AAA/BBB" is not xml, so I cannot run
an xpath or xslt on it...but ok, interpretation can be
probably 
done, in this case, because the expression is simple.

--(skip)
Almost surely one cannot do anything decent with the
xml of xsd 
either,  because you need to resolve references,
inheritance etc 
thus you would need a format where the actual schema
components are described, 
not only (one of) their syntax; I think they were
talking about 
this issue in some of this list yesterdays' messages.
I think anyway that once you have the xml of these
'resolved xsd components',
it is easier to use that instead of parsing and
interpreting the XPath rules and their relationships. 
--
I don't know if sch:rule/@context is restricted 
to be a simple xpath or if it can be any xpath
expression, in any case also with something simple
like (in case it is allowed in shematron):

AAA[not(CCC)]/BBB

writing is ok, verifying is ok, but interpreting the
correlation between 
validation and structure is imo the issue: it would
involve interpreting 
rules possibly written in many different ways. Once
you give power to 
the user, he will use it!

It is true anyway that probably it is not possible to
validate nor express 
such constraint with xml schema, thus it is evident
that schematron is more
powerful at least for validation.

With w3c schema it is also possible to write the same
thing in different ways 
but the cases are much more limited  (too many there
as well, in my opinion..).

I understand that using simple xpaths you could  check
if an
element is required or not (I use the schema for
creation
of user interfaces, and also for binding) but I have
the feeling
that potentially this parsing operation can get very
complex.

I have also the feeling that a grammar gives some
extra informations
apart the true/false and these infos can be used by an
application
for example while a user composes an instance, while
the assertion must be 
executed hoping that somebody associated to it a
meaningful message.
I am thinking also about a question made some weeks
ago and its solutions [1].

Don't consider me a grammar fan, they are even too
complicate and too
powerful! It is just that I think that they are more
understandable 
by a tool/application. But regarding the example of
[1] I think both assertions
and grammars fail (even if they are the only solution
available) 
in expressing-in-an-understandable-way the use case:
the required 
structure (a sort of "choice-set") should be part of
the type system in order 
to provide an easier way to understand and support it
in code
(I know not all cases can be covered, but this is a
recurring one).
--

Your posting is very accurate but unfortunately I
don't have the 
technical knowledge to understand all what you are
writing.
I like the idea of extension also if I didn't get it
fully.

I have some questions, may be they are inappropriate,
but
this is what I thought. Do not take them too seriously
and please don't take
this post as an attack to your technology, I sincerely
admire your independent
effort.


1) I found the simple type example interesting; I am
wondering if it is allowed 
to write an additional, contrasting, illogic, rule
like: 

---(before was less than 4, now I add more than 6)--
<sch:rule abstract="true" id="t3"
role="xsd-simpleType" >
	<sch:rule extends="t2" />
	<sch:assert test=". &gt; 6"
role="xsd-facet-maxExclusive">
	The value should be more than 6
	</sch:assert>
</sh:rule>
--

2) I am not sure about the one below because I don't
understand the syntax of the 
complex content example, but I see some dtd-syntax
(don't know
if it is actually used..).

>( BBB, CCC+, DDD | EEE, FFF? ')

If this is used by schematron, letting apart the issue
I mentioned before 
(parsing, interpreting, not xml), isn't using DTD
grammar a step backward ? 

3) I suppose schematron can express the semantics of
complex types 
derivation (extension I think is the issue here,
restriction
is just adding rules ?). Is it possible to roundtrip
complex types
derivation? 

4) How do you deal with (ignorable) wildcards ? I
suppose they are quite hard to 
insert in xpaths..if I have to deal with such
constructs in xslt I
usually do a first pass removing wildcard nodes and
then do an other
pass as they never existed. Otherwise expressions get
very complicate, in my opinion.

5) About types. If I know an <Employee> instance is
valid, is there
any possibility to know that <Employee> is  a <Person>
+ @EmployeeID ?

6) My last doubt is about the relations 
between XPath2 and W3C Schema: XPath2 depends on W3C
Schema, 
so isnt' that using xpath2  actually means using also 
somehow w3c schema ? Have you been assimilated ? ;-)

Cheers
Michele Vivoda

[1] http://lists.xml.org/archives/xml-dev/200711/msg00016.html


      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html