[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Suggested guidelines for using local types. (was Re: Enlightenment v
>The only way to overcome this using the current generation of >software is to >get everyone to enumerate every context in which a name can appear. > match="x:person/x:name | x:tedious/x:name | >x:pathetic/x:name | x:unworkable/x:name" >In other words, by treating _every_ name as local. Of course, then >when we add any new element we have to also add it as an >allowed context >on the matches for its children. Let me try to sum up a little bit my point. If think a lot of this thread relates to the fact that we don't agree on a simple fact : whether local elements defined in different global elements can have the same semantic or not. I missed the opportunity to raise this misunderstanding sooner in the "enlightement" thread, when you gave a template similar to the one above. For me, such elements don't have the same semantic, otherwise we would have used a global element instead. They wear the same name, but they just don't mean the same thing ; we need to know the context they are embedded into to understand their meaning, as their name itself is not sufficient. I don't think this is a bad idea to have context-sensitive semantics that do not rely on a single name, since a human reader or a computer program can easily handle this. Moreover, it enables you to "save room" in your global namespace, which means more room for extensibility and less chance of name clashs at the global namespace level. Now, if we consider that local elements defined in different global elements don't have the same semantics, I think that a template matching all local elements names does not mean anything. You can't associate the same behaviour to different semantics and expect the result to be meaningful. In the (crappy, I reckon) example we're working on, that means that you will never build a template that matches both a person's name and a product name, because they are semantically different. Thus, if you extend the schema and add a global element <deliveryCompany> in which a local element <name> is defined, you won't have to rewrite your templates, and you won't have any risk that the deliveryCompany/name will be interpreted as a person name or a product name. If you still want to match both a person's name and a product name, you know what you are doing and you enumerate the contexts you want to match. As by definition the semantics of local elements depend on their context, you would never, NEVER directly match on a local element's name, because you would not know what would be the semantic of the element you would be matching. If you think a global semantic such as a "name" exists, then do not hesitate, make it a global element ! However, for me, they are elements names that are very natural to use, such as "name", "price", "quantity", "address", and so forth, which are immediatly understood, but that also are too vague to be defined globally, outside of a context. It would be sad not to use them, tough, since they are so straightforward. So I would use these names in a local scope, not a global one, because defining a global semantic to the name "name" is too difficult, especially if you remember that a global semantic means a global behaviour of your program with regard to this name. Last, but not least, why not rename local elements to globally unique names ? 1) Because it does not improve readability, effectively making the documents more verbose <person> <person-name>Foo Bar</person-name> </person> is not more readable than <person> <name>Foo Bar</name> </person> 2) Because it does not simplifies template matching <xsl:template match="person-name"/> is not more simple than <xsl:template match="person/name"/> With some XSLT processor the first template could be more efficient to check than the second, but context sensitive processors will consider both templates equally (a context sensitive processor is able to activate/deactivate templates based on the current context, that is to say that within a <person> element, it would only check that the current element is named "name", and outside of a <person> element, it would not make the check at all). 3) Because you are cluttering the global namespace with names that only have a local meaning. What if you want to extend your schema, and discover that a very useful name to use as a global element name is already taken by an obscure local element ? 4) Because, in any event, a name is not the only thing that can be a key in an hashtable. If you DO need to associate some kind of behaviour to your data, based on its element name, you can do the same based on its canonical XPath, relative to the nearest global element. I've got a lot more to add, but I wanted to write this mail without mentioning PS*I :). Regards, Nicolas
|
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
|