Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Reserved names and documentation
 Assertion on: I personally feel namespaces as defined will implicitly REQUIRE everyone to explicitly tag each and every element which would be extra overhead and reduce the readability of the XML files. It also does not resolve your question about how to declare within the "primary" or "current" DTD that these "secondary" tags are allowed/disallowed. The problem appears to be that we have mixed, within the namespace redefinition of existing <tag>, a parser switch to another namespace while still parsing within the current namespace. Ouch! I think in general XML is best at making things EXPLICIT so this issue won't go away... /Assertion Suggestion On: A more explicit parser command tag like <EVENT namespace='new'> <all tags in new namespace use DTD from the new namespace> </EVENT> This is a push namespace event. enclosed <EVENTs> can push other additional namespaces, and the parser would know to switch DTDs and pop off at each </EVENT>. For your problem, the primary DTD would only need to explicitly allow <EVENT> commands within specified <TAGS>, but would not need to declare anything within the <EVENT> since we are now in new namespace parsing territory. /Suggestion Analysis On: The idea is we need to send namespace <EVENT> to the parser so it can switch between multiple DTDs. I don't think combining DTDs is necessary or even desirable. I think that the DTD element containing secondary <TAGS> should then explicitly allow <EVENT> tags as a new XML type to support this kind of syntax. Once the <EVENT> occurs, we are in the secondary DTD which does NOT have to allow namespace switching for example. Rather, I think that XML should have EVENTs that are clearly designed for parser interaction and explicitly tagged inside the DTD. The primary DTD could then in fact declare which new namespace changes it allowed, or could allow any random namespace. We seem to have implicit namespace <EVENT> already occuring according to the namespace spec, I am just suggesting we make them explicit as a way to handle your DTD concerns AND to avoid everyone explicitly sticking namespace into every element. Rather, they could explicitly change just the namespace WHILE STILL PARSING WITHIN the primary/current namespace/DTD, and then let the secondary DTD do its job with the next, incoming <TAG>. The secondary DTD does not even need to KNOW that it is within any namespace. Also, a new keyword like <EVENT> opens the door for some other parser directed possibilities. /2cents analysis Tell me if this makes any sense at all....just trying to help... >Now, on to the difficult problem: how do you go about making that >DTD I mentioned in step 1, that has the combined elements? Right now >we have little in the way of technology or automated procedures or even >industry experience to aid us in designing that compound DTD in a good, >clean, and efficient way. That's a hard problem and one that some >of the schema proposals are feeling toward a solution for. But we're >nowhere near knowing the answer. ...bryan F. Bryan Cooper 707 823 7324 VERITAS Software 707 321 3301 mobile Bryan.Cooper@v... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
