On Fri, Jul 27, 2007 at 06:50:42PM +1000, [EMAIL PROTECTED] wrote:
> On 27 Jul 03:45, Daniel Veillard wrote:
> }  We don't really have what you expect and for a variety of reasons:
> }    - first you can't systematically derive one kind of document from
> }      a schemas, it's like trying to derive one string from a complex
> }      regexp. You need schemas or regexps preceisely because your
> }      document or string can mute into various ways. It's a completely
> }      open problem if looked from a generic POV.
> 
> I understand what you mean - I assume you're referring to optional and
> repeating elements, for example.

  Right, in the case of RNG this is evem harder because the expressive power 
allows way more constructs.

> However I would be using my internal
> mapping of xpaths (or something similar) to drive which of those elements
> I would need to generate. So I guess I would be looking to use a
> combination of the schema and my own internal data mapping table. That
> should allow a specific document to be output. For example, if you
> traverse into a non-optional element and could find no match
> definition/xpath in the data mapping table or data callback then that
> would obviously be an error. Alternatively, you could default to null or
> empty values.
> 
> Anyway, that's my naive concept of what I want to do. Maybe I'll get
> further along and find it just won't work.

  Well I'm just stating that you need a lot of a priori knowledge beside
from just the schemas to really drive such generators.

> }  Sorry, but unless you basically copy some of the internal definitions in
> }your own code and try to hack your way in, it's just not possible as all
> }the data structures are opaque from an API viewpoint, and even then, it
> }may be really hard/impossible to get what you want just because the internal
> }structures are heavilly processed toward validation, not to be exposed as
> }'how the schemas look', for exemple we build regexp like internal validation
> }structure, which are compressed to binary tables to express element content
> }model, and getting from there to a possible instance would be far from 
> trivial.
> 
> Anyway, thanks for your reply. It sounds like nothing is in the library
> at present to do what I want. If I come up with a great solution that's
> fit for public consumption, I'll hassle you again with some patches. ;)

  okay, though the XSD part is a bit scary even for me :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml

Reply via email to