[
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">
<someMarkup/>
</de:reflect>
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 & 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.
--
Regards,
James William Pye
This is a digitally signed message part
|
