headers
Robin Berjon | 2 Jul 2004 20:22
Picon

attribute wildcards in open and extensible schemata

Hi,

I've been working on defining a RelaxNG schema for the upcoming SVG 1.2, 
which in turn involves also creating schemata for sXBL, XLink, and XML 
Events. Many parts of these specs have open content models, where 
arbitrary elements with arbitrary attributes are allowed recursively.

As you might expect, I keep hitting that problem where having an 
attribute wildcard creates a conflict with a declared attribute, and 
quite frankly it's driving me up the walls.

I've read the solution offered in Eric's excellent book, but it really 
looks to me like it is a work-around trying to defeat the system than a 
real solution. I've also investigating the option of tightly coupling 
these schemata (excluding their namespaces from the open part of the 
model and reincluding them explicitly) but that's really ugly, and isn't 
an option as those schemata are meant to work together out of the box 
but live their separate lives in separate specs (at least sXBL and SVG 
are to be official, normative, and separate, and we intend to send our 
XML Events RNG to the HTML WG for inclusion in 1.1 in case they like it).

Am I missing something? Is there a solution that I haven't thought of or 
missed in Eric's book? If not, would it be possible in future versions 
of RelaxNG to have something matching arbitrary attributes that haven't 
been matched already? It would be truly helpful for this whole compound 
documents shebang :)

Or should I just give up and hop straight to NRL?

Thanks for any insights,
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Cowan | 2 Jul 2004 20:45
Favicon

Re: attribute wildcards in open and extensible schemata

Robin Berjon scripsit:
> Hi,
> 
> I've been working on defining a RelaxNG schema for the upcoming SVG 1.2, 
> which in turn involves also creating schemata for sXBL, XLink, and XML 
> Events. Many parts of these specs have open content models, where 
> arbitrary elements with arbitrary attributes are allowed recursively.

You may find my non-normative XLink schema at
http://lists.xml.org/archives/xml-dev/200206/msg01074.html useful.

--

-- 
Is a chair finely made tragic or comic? Is the          John Cowan
portrait of Mona Lisa good if I desire to see           jcowan <at> reutershealth.com
it? Is the bust of Sir Philip Crampton lyrical,         www.ccil.org/~cowan
epical or dramatic?  If a man hacking in fury           www.reutershealth.com
at a block of wood make there an image of a cow,
is that image a work of art? If not, why not?               --Stephen Dedalus
Permalink | Reply | 1 comment |
headers
Tor Helland | 3 Jul 2004 10:29

Re: Recursive structure with restrictions

> > Playing with grammars, I found a solution demoed in the three documents
> > at the end of this email. I like the control I get over the structure,
> > and not repeating it.
> >
> > Is there a better way to achieve this, preferrably with one schema file?
> > Is there a simpler way, something obvious I have overlooked?
>
> Summer is here, and this list takes a dive, so I thought I had to answer
> myself.
>
> Using a general entity from the old xml and dtd world, I could replace the
> include element.

Summing up this monologue, just for the record :-)
And I still don't know if there are any better solutions.

Using the entity, I lose error reporting line numbers inside the entity
(using jing/xmlbuddy), and when I'm still coding the entity this is a
nuisance.
But the entity solution also allows me to include a pattern without
enclosing it
within a grammar, thus allowing easier access to global defines as well as
the
defines of the grammar containing the entity reference.

Using the include element, error reporting is good. But I don't like
splitting a structure across two files just for the mechanics of the schema
language. I like such splitting to reflect a separation of logic. (And in
the actual schema I was working on, not this demo, I ended up using two
entities.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Helka Folch | 11 Jul 2004 23:42
Picon
Favicon

including XLink attributes in RNG schema question

Hello,
I'm trying to write a Relax-ng schema to describe elements which have 
xlink href attributes attached to them. For instance, I want the schema 
to describe the following :

<node xmlns:xlink="http://www.w3.org/1999/xlink" >
  <use xlink:href="http://wwwhatever"/>
</node>

So, in my schema I include the RNG  schema for XLink (xlink.rng) and the 
reference to Xlink attributes :

<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<include href="xlink.rng"/>
<start>
<element name="node" >
         <element name="use">
                  <empty/>
                  <ref name="XLINK.simple.attlist"/>
          </element >
</element >
</start>
</grammar>

If I understand correctly, there are no default or fixed values for 
attribute definitions in RNG schemas. Does that mean that the required 
XLink attribute 'type' has to be specified on each element of the 
instance document that also uses the XLink attribute href,  for it to be 
valid?, like this :
(Continue reading)

Permalink | Reply | 0 comments |
headers
MURATA Makoto (FAMILY Given | 12 Jul 2004 00:05
Picon

Re: attribute wildcards in open and extensible schemata


> As you might expect, I keep hitting that problem where having an 
> attribute wildcard creates a conflict with a declared attribute, and 
> quite frankly it's driving me up the walls.

Could you show me a small example of this problem?  Some of us might 
be able to think of a better workaround.

> Am I missing something? Is there a solution that I haven't thought of or 
> missed in Eric's book? If not, would it be possible in future versions 
> of RelaxNG to have something matching arbitrary attributes that haven't 
> been matched already? It would be truly helpful for this whole compound 
> documents shebang :)
> 
> Or should I just give up and hop straight to NRL?

Although RELAX NG is intended to help schema modularization, I think that 
sophisticated use of namespaces require something like NRL.  It is expected 
to be approved as a Draft International Standard in September, 2004 at 
ISO/IEC SC34.

Cheers,

--

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
Permalink | Reply | 2 comments |
headers
MURATA Makoto (FAMILY Given | 12 Jul 2004 01:05
Picon

Re: attribute wildcards in open and extensible schemata


On Fri, 02 Jul 2004 20:22:32 +0200
Robin Berjon <robin.berjon <at> expway.fr> wrote:

> 
> I've read the solution offered in Eric's excellent book, but it really 
> looks to me like it is a work-around trying to defeat the system than a 
> real solution. 

I do not remember Eric's solution, but I will probably do this:

1) module (svg.rnc)

each attribute wildcard is defined as 
	awc = attribute * - (svgNamespace:* | local:*) {text}

2) customized module

include "svg.rnc" {
	awc = attribute * - (svgNamespace:* | xhtmlNamespace:* | local:*) {text}
}

3) combine customized modules

Use customized modules rather than svg.rnc.

--

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
Permalink | Reply | 0 comments |
headers
MURATA Makoto (FAMILY Given | 20 Jul 2004 01:05
Picon

Re: [relax-ng-comment] An RNC modularisation strategy question


On Mon, 19 Jul 2004 16:01:58 -0400
John Cowan <jcowan <at> reutershealth.com> wrote:

> > The resultant schema (as I understand it) is illegal because M2 is
> > included twice.
> 
> Correct.  That's because inclusion is flat (it does not introduce a name
> scope); when you include rules, you throw away the enclosing grammar pattern
> (implicit in the case of rnc format).

You might want to use nested grammars for avoding conflicts.  For example:

start = foo
foo =
  grammar {
    start = foo
    foo = element foo { empty }
  }

In this schema, we have two definitions of "foo".  But the first  and 
the second belong to different grammars and thus they do not conflict.

Cheers,

Makoto

--

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean McGrath | 20 Jul 2004 21:19

Re: [relax-ng-comment] An RNC modularisation strategy question

John Cowan wrote:

>One possible way forward for Sean's particular case, though not for the
>general case, would be to relax (:-)) RNG validity such that it is valid
>to have two definitions of the same name without a combination specified,
>provided the definitions are identical -- in which case, one of them is
>simply discarded.
>
>This seems like a reasonable extension to me.
>
>  
>
That would work perfectly for my scenario. I am looking into the other 
options mentioned but this would be by far the cleanest for my setup.

Some more details of the (possibly unconventional) way I lay out my schemas:

I use name definitions a lot. I use one for each element type in fact 
(no russian dolls and no nested grammers). I lay out my RNC's lile BNF 
grammers with  names playing the part of  "non-terminals". I use rigid 
naming conventions for filenames, namespaces, element types and the 
non-terminals to help me stay sane. e.g. the element type "foo" in 
namespace "R1234" will look like this:

    -- file R1234.rnc --
    namespace R1234 = "http://www.example.com/R1234"

    _R1234.FOO_ = element R1234:foo {
    }
    ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean McGrath | 19 Jul 2004 18:27

An RNC modularisation strategy question

I am creating a whole bunch of Relax NG schemas and seeking to
maximize re-use of schema fragments.

I am having trouble with multiple includes and seeking advise on how
best to deal with the one-include-per-file restriction.

Here is my setup/wishlist:
     All schema fragments stored in RNC and tranged via ANT to RNG/XSD/DTD.

     All schema fragments are usable standalone as well as modules of
bigger schemas.

     All schema fragments have their own namespace with a simple naming
convention
     that mirrors the file naming convention.

All schemas take the same basic shape. Here is the basic shape (for
any schema S):

    -- file S.rnc --
     namespace S = "http://example.com/S"

     # One of these for each schema fragment this schema uses.
     # Replace XXX with schema basefilename.
     include "XXX.rnc" { start |= notAllowed }

     start = _S.ROOT_

     _S.ROOT_ = element S:root {
              ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
MURATA Makoto (FAMILY Given | 26 Jul 2004 14:34
Picon

Re: attribute wildcards in open and extensible schemata

Robin,

> I can see where this makes sense and I could special-case for SVG by 
> excluding the attribute wildcard in there for elements in the SVG 
> namespace. But that gets tedious fast because a schema for SVG 1.2 also 
> has to cover XLink, XML Events, sXBL, and probably a dozen or so other 
> schemata that I'm forgetting about right now.

I understand the problem.  The "RELAX NG DTD Compatibility" spec (which 
is intended to mimick DTDs) is too restrictive about the use of identifiers.

I would then use RELAX NG as well as Schematron.  Schematron is very 
good at specifying IDs (even better than NRL).  Is this acceptable?

http://www.xml.com/pub/a/2004/02/11/relaxtron.html

Cheers,

--

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
Permalink | Reply | 0 comments |

Gmane