[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: dynamic elements
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|