OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Are we losing out because of grammars?



"K.Kawaguchi" wrote:
> 
> > If you're using RELAX for validation, it doesn't have any ambiguity
> > issues.  In this regard it is the same as TREX.  The ambiguity issues
> > only arise if you try to use it to "interpret" the document (that is
> > augment the information in the document by assigning each element or
> > attribute a label corresponding to some rule in the schema).  If you
> > just stick to validation, there's no issue.
> 
> You're right. And I read your tutorial that states
> 
> > The role of TREX is ... not to assist in interpretation of the
> > documents belonging to the class
> 
> (1) I think "assistance of the interpretation" is important requirement
>     of schema language (or at least I think there are solid needs).
>     But it seems to me that you don't share this view, do you. Why?

Aside from the technical point answered by James, I see a big danger in
transferring too much of "assistance of the interpretation" from the
documents themselves to the schema languages.

<rant>
Let's take the classical example of a book. A good practice using XML
1.0 and namespaces could be to define a generic namespace to describe
"people" and to use it to describe the author:

<book xmlns="http://example.org/ns/books">
  <title>....</title>
  <authors>
   <person xmlns="http://example.org/ns/people">
     <first-name>...</first-name>
     ...
   </person>
  </authors>
</book>

This is a good way to say that the person described here in the context
of a book has the same meaning that the same element from the same
namespace in another context.

Using "assistance of the interpretation" in this case means that you
will be able to assign any name and namespace to the elements and
attributes and rely on their datatypes (and on their namespaces).

You can then write:

<book xmlns="http://example.org/ns/books">
  <title>....</title>
  <authors>
   <person>
     <first-name>...</first-name>
     ...
   </person>
  </authors>
</book>

Or even

<book xmlns="http://example.org/ns/books">
  <title>....</title>
  <authors>
   <author>
     <fname>...</fname>
     ...
   </author>
  </authors>
</book>

and use a schema to indicate that {http://example.org/ns/books}:fname
has the same meaning than {http://example.org/ns/people}:first-name.

This is both useful -to define equivalencies between vocabularies- and
very dangerous because the processing of your document becomes dependent
on a heavyweight process and external documents.

Your document becomes more complex to read even for a human reader since
to understand what is the meaning of {http://example.org/ns/books}:fname
he needs to check the schema.

<conclusion>
This practice (and more generally all the practices built upon
information taken from the modified infoset) should be carefully
pondered before using it.

My gut feeling is that it's betraying the XML objective of self
documentation and of portability.
</conclusion>

</rant>

Eric

> (2) If we set aside ambiguity issue, it is easy to add "assistance"
>     capability to TREX, by (for example) introducing "type" attribute to
>     each <element> and <attribute> element in the pattern.
>     Do you have any reason to discourage this?
> 
> regards,
> ----------------------
> K.Kawaguchi
> E-Mail: k-kawa@bigfoot.com

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------