[
Lists Home |
Date Index |
Thread Index
]
Hi,
noah_mendelsohn@us.ibm.com wrote:
> Thank you for forwarding this. I've only had the opportunity to take a
> quick look, but it looks like an interesting piece of work. It's clear
> that finding appropriate means of capturing co-constraints will be very
> valuable to the XML community. I would be curious for your thoughts on
> the relationship between the desire for powerful constraint checking that
> the issues raised in the TAG finding, "The Rule of Least Power" [1].
IMHO, I would prefer "The Rule of Least Complexity" : W3C XML Schema are
more complex than my Active Schema : just consider the number of
elements that reflects in a certain way their respective inherent
complexity. Yet, some of them are very commons (an element declaration
is still an element declaration). However, they differ in their
capabilities to absorb complexity. Actually, I tried in Active Schema to
follow the main stream : XML dialects intend to be more and more mixed
together (SVG+Docbook+MathML) ; why this ability should be reserved to
XML documents other than schemata ? Thus, instead of designing "the +1
tag that covers the missing feature", which always consist on pushing
the limit of just a single step, I followed the main stream in Active
Schema ; in essence, Active Schema does almost the same things than W3C
XML Schema or Relax NG, but it can be combined at will with other
languages, which is increasing dramatically its expressiveness.
With Active Schema, you can express your content model as you think them
: "The content model of <foo> is a sequence of <foo1><foo2> if its "bar"
attribute value is "1", but a choice of <foo3><foo4> if its value is not
'1'"
<asl:element name="foo">
<xcl:if test="{ asl:element()/@bar = '1' }">
<xcl:then>
<asl:sequence>
<asl:element ref-elem="foo1"/>
<asl:element ref-elem="foo2"/>
</asl:sequence>
</xcl:then>
<xcl:else>
<asl:choice>
<asl:element ref-elem="foo3"/>
<asl:element ref-elem="foo4"/>
</asl:choice>
</xcl:else>
</xcl:if>
</asl:element>
...which consist on creating a dynamic content model. There is a mix of
2 languages here : one that designs the content model, one that supplies
imperative instructions (XCL stands for "the XML Control Language", ASL
for "the Active Schema Language").
http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-schema/active-schema.html
The power of ASL doesn't come from the language itself, but in the way
we can use it. "The Rule of Least Power" may be appliable out of the
using context.
It
> seems to me that, to the extent practical, it is desirable to focus on
> constraint languages that are simple and declarative,
Declarative languages are very expressive, but they cover a
well-delimited area from which it is impossible to escape from without
designing the famous +1 tag. The idea of ASL and of Active Tags in
general is to allow to mix at will declarative languages with imperative
instructions when the limits of the declarative language are reached.
http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-tags/active-tags.html
as I think that such
> approaches will greatly facilitate the development of tools for
> databinding, user interface creation, etc.
If you look at <asl:element>, <asl:sequence>, and <asl:choice> above,
they are components ; the dynamic content approach brought something
very new and unusual in data binding : usually, the way to plug
components together is hard-coded thanks to an XML file :
<component1>
<component2/>
<component3/>
</component1>
The new way to design components is to consider a runtime phase before
invoking the master component :
<component1>
<xcl:if test="...">
<xcl:then>
<component2/>
<component3/>
</xcl:then>
<xcl:else>
<component3/>
<component4/>
</xcl:else>
</xcl:if>
</component1>
...which can be render as :
<component1>
<component2/>
<component3/>
</component1>
or
<component1>
<component3/>
<component4/>
</component1>
ASL works in the same way.
Once the tool that support such dynamic data binding is implemented, it
is not hard to design the components that rely on it.
See :
http://reflex.gforge.inria.fr/
Now, there is also a very new approach in term of content modelling ;
for the design of the above component, we can't design in a classical
way its content model, because the subcomponents it can accepts are
known at runtime ; so, could we say that component1 is either a DYNAMIC
component2 followed by a DYNAMIC component3 or a DYNAMIC component3
followed by a DYNAMIC component4 ? This is another story...
I don't think I've reviewed
> your proposal in enough detail to have an informed opinion, but a quick
> skim suggested that it points toward using somewhat more "powerful"
> languages. These presumably have the advantage that they can effectively
> express more elaborate constraints, but sometimes at the cost of making it
> difficult to easily discover that a particular constraint is in fact a
> straightforward one. This is a tradeoff that the Schema WG has been
> wrestling with, as there too, some members are inclined torward approaches
> that are more powerful (in the sense of the finding), and some are willing
> to leave behind more difficult use cases in favor of a solution that's
> easier to optimize and easier to reason about. I'm curious whether you
> have considered such tradeoffs.
One solution, IMHO, doesn't rely on a sort of tag race, but rather on
the ability to combine several dialects in the way described above.
This enforces to design new *active* languages much lighter than it
would be ; have a closer look at ASL that defines only 20 elements.
Regarding the pros and cons about the power of a schema language, I
would argue that a constraint not expressible in the schema must be
expressed anyway in another language (Java, C++, PHP, or other) which is
very unfavourable :
-the constraints are disseminated,
-the datas to check won't be as easily accessible as within the schema
(lost of context, host language not XML friendly, etc)
Thanks very much.
>
> Noah
>
> [1] http://www.w3.org/2001/tag/doc/leastPower
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Philippe Poulard <Philippe.Poulard@sophia.inria.fr>
> 05/15/2006 05:41 AM
>
> To: noah_mendelsohn@us.ibm.com
> cc: Michael Kay <mike@saxonica.com>, "'Crni Gorac'"
> <cgorac@gmail.com>, xmlschema-dev@w3.org
> Subject: Re: specify element type depending of same element
> attribute value?
>
>
> noah_mendelsohn@us.ibm.com wrote:
>
>>And, adding to Mike's answer, the schema workgroup is devoting a lot of
>>effort to choosing the right features for Schema 1.1 that would allow
>
> just
>
>>such co-occurrence constraints to be expressed. Though I can't
>
> officially
>
>>commit anything, I would expect to see at least some initial proposals
>
> in
>
>>whatever is the next public working draft of the Schema 1.1
>
> specification.
>
>> Stay tuned.
>>
>
>
> hi,
>
> I'm playing with an alternate schema technology that can build content
> models dynamically, as shown in this example :
> http://reflex.gforge.inria.fr/tutorial.html#N801359
>
> Thus, co-occurrence constraints are easy to achieve with the Active
> Schema Language :
> http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-schema/active-schema.html
>
>
> Of course, this is still experimental, but it's worth seeing ; there are
> lots of ideas that might interest the schema workgroup.
>
--
Cordialement,
///
(. .)
--------ooO--(_)--Ooo--------
| Philippe Poulard |
-----------------------------
http://reflex.gforge.inria.fr/
Have the RefleX !
|
