Relax NG and XInclude?

[drmtwr]

Hi,

Can anyone tell me if XMetaL plans to incorporate Relax NG and XInclude standards in future releases?

http://en.wikipedia.org/wiki/XInclude

http://en.wikipedia.org/wiki/RELAX_NG

If XMetaL included these standards we could start using it again. As it stands today, we are forced to use another authoring tool.

Thanks,

Dave

Reply

[dcramer]

Likewise, if XMetaL supported these, I would consider upgrading. As it is, I don't have any reason to.

Reply

[nhu]

What is your expectation or requirements for an XML Authoring tool to support XInclude?

Reply

[AlanHouser]

I would be curious to know what tools you are using that do support these standards. Support for XInclude and RelaxNG has been sparse among XML tools in general, and nearly non-existent in document-oriented XML authoring tools.

-Alan
—
Alan Houser, President
Group Wellesley, Inc.
412-363-3481
http://www.groupwellesley.com

Reply

[dcramer]

oXygen and XMLMind both support xinclude. oXygen also supports relaxng.

The first requirement would be to resolve the xincludes during validation.

For editing, ideally the editor would display the xincluded content and you could edit it inline (like Serna does with file entities). I suppose if the file is locked on the filesystem, you might not let them edit that portion of the file. If that's too hard, you could do it like XMetaL does with file entites now (except it would be easier since the files you're opening have DOCTYPEs…XMetaL has serious limitations wrt opening entities as it is).

It seems like conref is just xinclude with a different syntax. Couldn't you leverage your work with conrefs to support xinclude? It's been a while since I looked at the DITA version of XMetaL, so I don't recall how it supports conrefs.

David

Reply

[mag3737]

Leveraging our conref implementation is certainly something we have thought about for adding XInclude support, but I'm not about to make any claims or predictions about the development roadmap here in the forum.  😮

FWIW we don't currently allow inline editing of conrefs, but we do have “Open Referenced File” on the context menu when you right-click on one.

Reply

[Derek Read]

To make mag3737's reply a little more clear, conref is the DITA equivalent of Xinclude (this is the General discussion board, not DITA so people reading here might not be familiar with that concept). It isn't exactly the same but is close enough that for most people the end result is the same. So, currently if you are working with DITA documents that is really the way to go (more because that is what DITA recommends than for any other reason). In theory we could extend how the product currently supports DITA conrefs to implement support for XInclude. We don't talk publicly about what is currently on or off of our current roadmap though (unless it is likely to never happen), so I can't give a clear answer or dates here.

It is unlikely that we would support RelaxNG anytime soon. The number of clients using DTDs and Schemas far outweigh the number of serious requests we've had for support for RelaxNG to date. Of course, nothing is ever set in stone, and I don't profess to talk on behalf of our management team  (they ultimately make the final decisions on these types of things). It is more likely (in the near term) that we will spend time improving our (W3C) Schema support than implementing a brand new schema type like RelaxNG.

If you know of a specific standard (ie: not proprietary) document model implemented in RelaxNG that is not also implemented as a Schema or DTD (or cannot be implemented as such) I would be interested in that information. That might also be a driving force behind RelaxHG implementation if the particular document model is one many people are interested in using.

Reply

[dcramer]

Of the two, xinclude is the more important to me, especially given the difficulties XMetaL has with entities.

Thanks,
David

Reply

[Derek Read]

Of the two, xinclude is the more important to me, especially given the difficulties XMetaL has with entities.

Interesting. I assume you are referring to file entities, aka external general entities (and not character, text or graphic entities, all of which are supported). Given the choice, would you prefer we improve the UI for working with file entities or is there a really compelling reason that XInclude is much more attractive? What exactly is it about the file entity support that you don't like:
1) You must open them in a separate document window to edit them (double click does this).
2) They don't render 'inline' (in context of the containing document).
3) When a validation error is found inside the content of the external entity while validation the containing document you cannot get to it easily (as per #1).

What we've implemented for DITA conrefs addresses #2 (in the context of DITA only at the moment).

Reply

[dcramer]

You are correct, I'm talking about file entities, not graphic entities and text entities mostly work.

I would prefer xinclude support. Entities are cheesy SGML cruft.

#3 is annoying, but there are several other limitations:

If you double click on entity icon in the main (with a DOCTYPE) file, XMetaL is fine and gives you all the editing help in the sub file that you would have in the main file. However if you reload the sub-file entity, you are prompted to find the DTD. I think this could be worked around if XMetaL knew to look for a PI or something that indicated the location of the parent doc (and/or DTD). Likewise, if you press F9 to validate in an included file, it obviously can't validate because there's no DOCTYPE, but there's no build in mechanism to indicate the name of the parent document. I worked around this one with some scripting that looks for a PI to tell it the name of the parent document. But that kind of thing could be built in. I guess I could post my scripts here.

If you have a file entity within a file entity, XMetaL loses the ability to give you any editing assistance, all macros stop working, etc. So basically you just can't do that. Again, if XMetaL knew to look for a PI pointing to the parent doc, it could parse that doc's DOCTYPE and keep going.

If you use text entities in file entities, XMetaL doesn't resolve them in the file entity like it does in the main book. You only see a box with the entity name.

You run into problems if you use file entities and text entities with preview:
1. Declare a file entity (foo, referring to foo.xml), the corresponding file (foo.xml), and a text entity (bar, with a value of baz) in the DOCTYPE.
2. Reference the file entity in the document.
3. Reference the text entity in the file entity,
When you try to preview the document in the preview pane, you get an error. If you inspect the temp file it creates for the preview, HM3A.xml, sure enough, &foo.xml; and its declaration are there, but the declaration of the bar entity is missing. I’m surprised it doesn’t just resolve all the entities for the purposes of the temp file.

I recall some problem with catalog files and entities too, but I'd have to dig in old emails to find them.

David

Reply

[nhu]

Is there any editor which supports in-place editing XInclude?  I do not think oXygen does. 

Ning

Reply

[dcramer]

Click to open the xincluded document is fine and, now that I think about it, probably safer than letting someone edit a random element of one document from another.

One feature/mechanism I'd also like to see in the xinclude support is a way to crossreference to xincluded content such that you can pick the title of the xref target from a list. I'd have to research what the correct DocBook way of doing this is though…I think it may be using olinks. One limitation of XMetaL (or my customization of it) is that, using a little IDREF picker I found in an old version of the journalist demo, you only get to pick from IDREFs in the active document and even then, you're presented with a list of the IDs, not the titles. I have another mechanism using the resource manager and an xslt, but that approach has problems too and I haven't spent enough time on it to refine them away.

Currently for DocBook users you have to do a lot of scripting before XMetaL becomes a usable tool for authors. Basic tasks like crossreferencing, inserting images, and such should be usable out of the box. 

David

Reply

[mag3737]

“Out of the box” is not possible, of course, because what did you say the name of your link element was, again?  Although it's true that XMetaL makes good guesses about other element names, and DocBook has sensible names for things, so…

The missing bit here is “treat as link”, akin to XMetaL's intrinsic knowledge of certain other element types (graphics, toggles, etc.).  We are looking at adding links to its “treat as” types.  I don't know if the XMetaLOldTimer would have anything more to say about it here yet.

Reply

[mag3737]

My earlier answer seems a bit hastily incomplete.  What “treat as link” will do, when we have it someday, is let you make links work with a “simple matter of configuration”.  I.e., all you will need to do is signify to XMetaL (through the CTM or another config file) that the name of the link element in your DTD is and the attribute name for the target location is “href”, and then certain things that should “just work” will indeed just work — any time the user inserts a , they will be automatically asked to browse to find the thing it should link to.

Reply

[dcramer]

You could have out of the box support for DocBook and its standard mechanisms the way you do for DITA. Configurability via ctm or whatever would make it easier to adapt to homegrown and DocBook-like DTDs.

My resource manager solution involves running an xslt over the parent-document, then generating a toc tree of titles. When you click on a title in that tree, it inserts an xref to that element. It's pretty simple. The problem is that for a large document, it's too slow, so I need some way to cache the results and maybe only refresh when the user asks it to. Also, I need to add some search features, so it will display, e.g. only procedure titles, or only titles containing some expression.

Reply

[Author]

Posts