Martin,
Le mercredi 02 novembre 2005 à 18:05 +0000, Martin Bryan a écrit :
> Eric
>
> >> My take on this is that what.content is wrong:
>
> >What do you mean by wrong?
>
> >If you mean "uncommon" or "not easy to describe with tools such as W3C
> XML Schema" I agree that this content is "wrong".
>
> >Personally, I try to avoid using terms such as "wrong" that carry a
> judgment except when something is really against the spec (for instance
> when a document isn't well formed).
>
> >Here, I don't really think that we can say that this is wrong!
>
> OK, not wrong, just misguided :-)
That's worse since I am the guide who has provided this guidance :-) ...
> Seriously, what you are after are the set of nametokens that are valid at a
> particular point. What your example is trying to do is to define a model
> that is valid at a particular point. I am not convinced that defining a
> model is valid in this context.
Valid in the meaning of easy to valid with W3C XML Schema, probably not.
Otherwise, why not?
> > > what.content =
> > > element foo1 {
> > > element bar1 {empty}? &
> > > element baz1 {empty}? &
> > > element bat {empty}?
> > > } | element foo2 {
> > > element bar2 {empty}? &
> > > element baz2 {empty}? &
> > > element bat {empty}?
> > > }
>
> My main point is the following:
>
> > The question you are really asking is "what.foo1" and "what.foo2" (note
> the
> > namespace/qualification). The options are not a model, but a list of
> tokens
> > that are element names in the original schema, so they should be defined
> as
> > attributes, not elements.
> >
> > So we seem to be talking about something like:
> >
> > what.content = element what.foo1 {attribute element.name (bar1|baz1|bat)}
> |
> > element what.foo2 {attribute element.name (bar2|baz2|bat)}
>
> You state:
>
> >This would be against the principles of a "QBE" where we try to express
> as much as possible by providing examples.
>
> Eaxmples of what: matching models or matching instance constructs?
Examples of matching instance constructs.
> For matching instance constructs XPath is ideal (foo1/bar1 | foo1/baz1 |
> foo1/bat). It also maps easily to XSLT.
>
> Why do you think you need a model definition in your example?
Because otherwise, that's just too easy to write queries that are not
valid, also because Oxygen gives you a guidance when you write a query
if you attach a schema and because it releases the application that
processes the queries to provide user friendly messages when a query is
invalid.
These are the typical reasons why you usually want to use a schema and
they fully apply in that case...
> >Furthermore, you would need to specify namespaces for these element
> names and that could lead either to very long names or to QNames which
> are an horror.
>
> Again XPath solves this easily, without needing a model.
In the paper that I have quoted in my first mail
(http://dyomedea.com/papers/2005-extreme/xmlRdfQbe.html), I explain why
we don't want to use XPath in this application.
The application needs to be neutral in regard to the underlying
technology. Currently, the data is stored in a LDAP directory but
tomorrow it could be stored in a XML or a RDF database.
Furthermore, the application will be used by LDAP, XML and RDF heads and
we want to provide something that make sense for all of them.
We had three existing candidates for our query language: LDAP filters,
XQuery/XPath and RDF query languages.
Each of them would have more or less locked the application to one of
the three target technologies (we do not want to write LDAP filters on
top of a XML or a RDF database, nor to implement XQuery/XPath on top of
a LDAP repository or RDF database nor to implement a RDF query language
on top of a LDAP repository or XML database).
Also, using XPath does make absolutely no sense to someone who looks at
the information as RDF triples.
That's the reason why we have chosen to define this simple query
language that works as a QBE.
This QBE as already been implemented as a proof of concept on top of
XQuery and I am now finishing to implement it on top of LDAP.
I hadn't anticipated that the example could be so controversial :-)...
If that's the case, never mind, just forget it!
The solution I have adopted to generate the schemas are to simplify the
RNG schema for the target language using a variant of the XSLT
transformation I have publish to simplify RNG schemas and write a XSLT
transformation that transforms this simplified schema into a schema for
the QBE.
Note that the same approach could probably be used to generate specific
schemas describing XSLT transformations for a target vocabulary.
This is most probably in the scope of all the pipeline languages that
are candidate for part 10.
Eric
--
Lisez-moi sur XMLfr.
http://xmlfr.org/index/person/eric+van+der+vlist/
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
DSDL members discussion list
To unsubscribe, please send a message with the
command "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)
Received on Thu Nov 3 16:53:07 2005
This archive was generated by hypermail 2.1.8 : Fri Nov 04 2005 - 01:33:02 UTC