OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] dynamic elements

[ Lists Home | Date Index | Thread Index ]

On Mon, 2004-10-25 at 11:44, Liam Quin wrote:
> As you note, you can already do this in XInclude.
> It doesn't work in attribute values, though --

Precisely why a compact [dynamic] element syntax is needed, at least in
this extension. I think the S-Expression style works quite nicely in the
context of attribute values, and perhaps even attractive.

$(ns:element_title[ns:attr='optional attribute'] $(ns:child_element))

Really, I would expect most use be as simple as "$(ns:element)".

And as far as the XInclude comparision is concerned, dynamic elements
would be a much more general mechanism; where within the scope of
dynamic elements, XInclude would be a specific source of a set of
elements(only the 'include' element, afaik).

> This sort of approach (using element syntax for replaceable
> content) has been discussed before, and has been deployed in
> environments ranging from semiconductor data sheets to
> transcriptions of historical texts.

I figured as much. I even loosely consider <br/> in [X]HTML to be a
specific example of this[perhaps more remotely, than closely tho :].

> But then you sometimes want to strip out the markup, so you end
> up with multiple defintions or with something like
>     <constant name="companyName" format="plain" />

Yes, I think using namespace'd attribute "arguments" would be ideal
here. For instance, regardless of the source, one would be able to
<char:amp de:format="plain"/>, of course this instance would be
pointless, but it illustrates the use of attribute arguments in a 'de'
general fashion. Hrm, that is, this is something that the 'dynamic
elements' implementation would handle, as opposed to the actual source.

This would play a part in the compact attribute value syntax. de:format
would be a fixed default of 'plain' when elements are referenced in
attribute values. Attempts to overload it would probably just be ignored
or errored.

Interestingly, using a reflective macro/function, one could create a
similar effect to CDATA sections:

<de:reflect de:format="plain">

Would output the literal text '\n<someMarkup/>\n'.

Of course one wouldn't get the complete benefit of a CDATA section in
still having to use &amp; or <char:amp/> or whatever.

(reflect would probably be built into the general mechanism as reflect
would be to XML as to echo is to sh, barring a few differences of course

> The contribution of namespaces here is perhaps that schema writers could
> incorporate the namespace more easily, although it also may make life
> harder for DtD writers.

I would think at first that all of that would really apply to
non-[dynamic element]-supporting validators[processors], considering the
potential volatility of the effect the elements would have on the
document, one should/would need to expand all the references before
validating; much like how I have to pass --post-valid to xmllint to get
it to validate my DocBook(as I use XInclude). Of course if I tweaked to
the DTD to recognize xi:include, it wouldn't be necessary. Although,
that doesn't seem quite Right as it wouldn't actually be validating the
entire book unless it expanded those XIncludes.

But yes, for non-supporting validators, it could be a pain.

        James William Pye

This is a digitally signed message part


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS