Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Alternative "character entity" proposal
 I think Richard's proposal is pretty good: I have no particular architectural problems with it, just a technical druther against adding more scoped declarations. But I am not sure that it solves adequately the problems that (I think) it is predicated on. All the named reference proposals are predicated that people will be using tools without adequate input methods, in particular dumb text editors. (The issue of inadequate display methods doesn't seem so important, because the characters that most people don't have glyphs for tend not to have strandard entity names either, except for the Maths characters.) Then Richard's proposal provides a way to make your own names. This naturally means that, to allow combination, you need scoping to prevent clashing definitions. However, if you were to cut some fragment with a text editor, you need to bubble down the entity definitions and move them with the fragment (as is the case with namespace declarations and ,differently, @xsi:schemaLocation). So for this to work well, it really needs some kind of editor-assistance, otherwise it is a tedious search. But we have already started from the assumption we are using some fairly simple text editor. But the need for scoping only comes from the need to define your own entities. Just limiting to the standard entities means there is less need for scoped declaration. I guess there is also a possible intermediate point between my proposal and Richard's: just the @xmlentfile attribute to allow reference to a (predefined set?) of known entity declarations, but no @xmlent attribute. But if people are too lazy (? no...busy) to type in a dummy DOCTYPE with external references, they would be too busy for this. I think Richard's comment suggests another really good point: should we in fact be moving to a split XML model: a server-side syntax with numeric character references, entities, CDATA, etc, and a client-side XML with all sugar free? Servers already do the XSLT, PHP etc processing: should this be really part of their job. In other words, should W3C persue a policy of moving XML for transmission towards Canonical XML, while simultaneously moving XML for writing towards something with more sugar (such as ECS, Editing Concrete Syntax[1])? Cheers Rick Jelliffe [1] http://www.topologi.com/resources/pdfs/ECS.pdf 
|
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
|
|||||||||
