Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Notations, subschemas, entities
 John> John Cowan <URL:mailto:cowan@l...> => In article <3576FB58.39B139D4@l...>, John wrote: John> Toby Speight wrote: >> I can't remember (nor find easily in the spec) whether notations >> must be declared before use. John> There seems to be no such requirement. The VC simply says: John> "Values of this type [i.e., notation] must match one of the John> notation names included in the declaration; all notation names John> in the declaration must be declared." Yes, that's all I could find. John> Indeed, I'm thinking that XSchemas should have structure, ... >> Sorry, you lost me with this paragraph. Can you illustrate it with an >> example? John> In other words: John> John> <DOCTYPE root="blah"> John> <DOCTYPE> John> <ELEMENT id="blah"> ... </ELEMENT> John> <ELEMENT id="bazz"> ... </ELEMENT> John> <NOTATION id="foo"> ... </ELEMENT> John> </DOCTYPE> John> <DOCTYPE> John> <ELEMENT id="zim"> ... </ELEMENT> John> <DOCTYPE> John> <ENTITY ...> ... </ENTITY> John> <ENTITY ...> ... </ENTITY> John> <ELEMENT id="zam"> ... </ELEMENT> John> </DOCTYPE> John> </DOCTYPE> Ah, I see. While it does mean there are many functionally-equivalent XSchemas for a given DTD, I have no real objection to this (although if I were creating reusable XSchema fragments, I'd stick the ELEMENT etc. declarations in a separate file, and have my XSchema reference them. I'm not 100% convinced of the utility of importing a schema that hasn't been designed for re-use. John> My concern is that we will bloat the simple XSchema DTD with John> elements for marking up fancy text. If we were going to do John> that, we'd need a subschema (see above!) that handled just the John> bare bones of fancy text, ... Yes, that's a danger. I think we need to thrash out documentation issues in a separate discussion. Unfortunately, I may be unable to see it through to the end, as I'm on holiday from 13th June until the end of the month. >> <!ELEMENT EXTERNAL-ENTITY (DOC?)> >> <!ATTLIST EXTERNAL-ENTITY >> %external; >> notation CDATA #IMPLIED> >> <!ELEMENT INTERNAL-ENTITY (DOC?)> >> <!ATTLIST INTERNAL-ENTITY >> value CDATA #REQUIRED> John> Using an attribute value to hold the definition of an internal John> entity involves processing out all markup characters (&, <, ', John> "), thus: John> John> <!ENTITY yutz 'I use &int-entity; and refer to "&ext-entity;"'> John> John> would come out as John> John> <INTERNAL-ENTITY value="I use &int-entity; and refer to John> "&ext-entity;""/> John> John> whereas John> John> <INTERNAL-ENTITY><![CDATA[I use &int-entity; and refer to John> "&ext-entity;"]]></INTERNAL-ENTITY> John> John> is far more readable and writable. John> John> The spec should say that the content of an ENTITY element should be John> wrapped in a CDATA marked section. "Should" might be wording it too strongly. I agree with your point here, but I think it's orthogonal to whether internal and external entities should use the same element type. I like the value-as-content as you wrote it above, if EXTERNAL-ENTITY remains as I wrote. The reason I didn't put the value as content was due to my allowance for DOC; we'd need <!ELEMENT INTERNAL-ENTITY (DOC?, LITERAL)> <!ELEMENT LITERAL (#PCDATA)> to satisfy XML's restrictions on mixed content. -- 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
|
|||||||||
