[dsdl-discuss] Re: FW: [office-comment] Ambiguity problems caused by a:defaultValue

From: Innovimax SARL <innovimax@gmail.com>
Date: Tue May 13 2008 - 20:29:02 UTC

Neat !!

Ok so for this to be streamable we need to put restriction on
selector/@path and field/@path

I would go for

selector/@path ::= simple path (of the form foo/bar/foobar/@barfoo)
field/@path ::= @foo or text()

Is this sufficient

If it is not, we probably could add positional predicate
(foo[1]/bar[3]/foobar[2]/@barfoo)

Mohamed

On Tue, May 13, 2008 at 4:13 PM, MURATA Makoto
<murata@hokkaido.email.ne.jp> wrote:
> > Isn't the declaration of ID simple enough to let the implemter do what
> > he has to do ?
> >
> > something like
> >
> > <declare-id context="simple_xpath | simple_xpath"/>
> > <declare-idref context="simple_xpath | simple_xpath"/>
> >
> > isn't just sufficient ?
>
> I suppose that you intend to create a tiny language for
> identity constraints. I think that your goal is sensible.
>
> W3C XML Schema provides multi-part keys: a selector may have
> more than one field. These fields collectively become a key.
> Although I do not think that multi-part keys are strongly
> required, I would like to make sure that multi-part keys can
> be easily added later. So, I think that we should separate
> selectors and fields.
>
> Here is my suggestion.
>
> 1. Example
>
> <identityConstraints>
> <key name="...">
> <selector path="..">
> <field path=".."/>
> </selector>
> </key>
> <keyref name="..." keyName="....">
> <selector path="..">
> <field path=".."/>
> </selector>
> </keyref>
> </identityConstraints>
>
> 2. Syntax
>
> start = element identityConstraints { (key | keyref)*}
> key = element key {attribute name {xsd:NCName}, selector }
> selector = element selector { attribute path { text} , field}
> field = element field { attribute path { text }}
> keyref = element keyref {attribute name {xsd:NCName}, attribute keyName {xsd:NCName}, selector }
> selector = element selector { attribute path { text} , field}
> field = element field { attribute path { text }}
>
>
> 3. Design choices
>
> Multi-part keys: No (unlike W3C XML Schema)
> Hierarchical keys: No (as in W3C XML Schema)
> Key scopes: Global only (unlike W3C XML Schema)
> Typed keys: No (unlike W3C XML Schema)
> Multiple key/keyref symbol spaces: Yes (as in W3C XML Schema)
> Keys in elements: Yes (as in W3C XML Schema)
> IDREF*S*. No (as in W3C XML Schema)
> Separation from validation: Yes (unlike W3C XML Schema)
> Mandatory keys: Yes (i.e., no xsd:unique)
> More than one key per element is allowed.
>
>
> P.S. you might want to have a look at the old archive of RELAX NG TC
>
> http://lists.oasis-open.org/archives/relax-ng/200104/maillist.html
>
>
> --
> MURATA Makoto <murata@hokkaido.email.ne.jp>
>
> --
>
>
> 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)
>
>

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €
--
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 Tue May 13 22:29:08 2008

This archive was generated by hypermail 2.1.8 : Tue May 13 2008 - 22:43:02 UTC