|
Bryan pointed out to me in person: This is just further getting ourselves away from 'proper' xml by defining our own lookup mechanism. I agree with him that that's not great. As he more or less said, what's the point of even using XML if we're just going to circumvent half of the validation/definition mechanism? But part of what I'm trying to do is just get people to be creative about solutions to this problem. The problem I see is not that XML namespaces are bad, but more that parcel.xml is a ridiculously complex system for the few specific uses most developers will need it for. Another idea I had, related: domain-specific XML. Right now parcel.xml is this unifying mechanism for defining all data.. but if users are mostly defining one or two types of data (UI elements, and maybe wakeup callers) perhaps we could think about some domain-specific schemas for some of this.... for example, block XML which would look like HTML or XUL... in that specific case, we could define a decent schema which covered 99% of UI declarations, and use things like namespaces to add custom tags and the like. Alec Alec Flett wrote: For example, using <parcelpath> from above: Another idea I thought of after sending this: <parcelref prefix="foo" parcelpath="..."> <someKind parcelref="foo">... Admittedly a little obtuse, not really much better than namespaces.. and either system would prevent any kind of "validation" - i.e. verifying Alec This might mean "for all future tags in this document, look up the Kind in this parcelpath." |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
