"As noted, the whole thing changes with schemas." but schemas themselves are XML 1.0 documents and as far as i know will never fully replace DTDs (as a requirement) so the old functionality will always have to be there regardless of if you're using a schema or DTD to validate your XML if for no other reason than backwards-compatibility. it appears that Xerces builds an internal schema DOM from the DTD, evidenced by the "http://apache.org/xml/features/domx/grammar-access"; attribute - i wonder when Xerces2 will support this attribute? (i use it to build logical models of DTDs without having to use a DTD parser (since Xerces, obviously, has to have one built-in)). it's also a nice way to learn a little XML Schema if you already understand DTDs.
-----Original Message----- From: Don Smith [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2001 7:23 AM To: [EMAIL PROTECTED] Subject: RE: dtd question >so you're saying that namespaces are interpretation-level, not >validation/parsing-level information? Yes, for validating processors that meet the requirements of the XML 1.0 Rec. (But not for schema validation.) >in some strange way it >seems like you're doing the same job (validation) twice (at least), though i >suppose with different information and rules to apply... Not validating twice. I think of it as a pipeline: validate first (no namespace awareness), pass the output to the next application for further processing (which can be namespace aware). As noted, the whole thing changes with schemas. Regards, Don ISOGEN International -----Original Message----- From: Reynolds, Ron [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2001 9:08 AM To: '[EMAIL PROTECTED]' Subject: RE: dtd question so you're saying that namespaces are interpretation-level, not validation/parsing-level information? basically an XML document is an XML document to a parser/validator, but how that resulting document is interpreted is where namespaces are applicable (at which point you better be able to figure out what you have as far as those more ambiguous elements...). so there would have to be a validation part to interpreting the document as well (things which were valid to the parser/DTD-validator are still not necessarily valid to a namespace-aware interpretation layer). weird... makes sense (sorta) but still weird... in some strange way it seems like you're doing the same job (validation) twice (at least), though i suppose with different information and rules to apply... -----Original Message----- From: Don Smith [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:58 AM To: [EMAIL PROTECTED] Subject: RE: dtd question Right on the syntax points. I'm doubtful about any "more complex logic" being applied. :) I think the key is distinguishing between XML 1.0 validation (which is not namespace aware, even if the names in the DTD have colons), and namespace processing of document instances which may have been validated by an XML 1.0 parser, but are now being processed (not validated) by namespace aware applications. Regards, Don ISOGEN International -----Original Message----- From: Reynolds, Ron [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2001 8:45 AM To: '[EMAIL PROTECTED]' Subject: RE: dtd question hmm..., according to the XML 1.0 spec (19980210): NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender Name ::= (Letter | '_' | ':')(NameChar)* so i could have elements (no namespaces) like this: "<:foo>", "<:::>", and "<foo:bar>". (and elements like "<:_.-::_>" if i was feeling really crazy. odd we never see elements like this...) according to the Namespaces in XML doc (19990114): NCName ::= (Letter | '_')(NCNameChar)* NCNameChar ::= Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender QName ::= (Prefix ':')? LocalPart which makes the above elements illegal if namespaces are enabled and there is no "foo" namespace for the second element. (do the first two become illegal regardless? i would expect so...) it seems like this would lead to ambiguities when deciding what namespace (assuming it's enabled) an element resolves to otherwise. are these rules swapped depending on whether namespaces are or are not enabled? or is some more complex logic applied to decide which rules to apply to an encountered element? enquiring minds want to know... :) ...................ron. -----Original Message----- From: Don Smith [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2001 6:23 AM To: [EMAIL PROTECTED] Subject: RE: dtd question Dimitri: They have hardcoded the namespace, and it is perfectly legal in XML 1.0: the parser simply looks at this as a name, which allows the colon. It does not look at this as a qualified name consisting of a prefix and local name. However, when a document instance is created, it can be processed by a namespace aware processor. BTW, there are probably also one or more attributes declared for the attribute "xmlns" and possibly a fixed declared value for the namespace URI. Regards, Don Smith ISOGEN International -----Original Message----- From: Dmitri Colebatch [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2001 9:54 PM To: [EMAIL PROTECTED] Subject: dtd question hey guys, I'm looking at xmldb (http://www.xmldb.org) and have just found a dtd of theirs that looks odd. Its appended to the end of this message, but the guts of the oddness is an element declaration with a ":" in it... ie: <!ELEMENT xupdate:text (#PCDATA)> now to me this looks like they're trying to emulate ns, by effectively hardcoding it.... but for all I know it could be perfectly legal, hence asking... someone give me some sort of an answer here? cheers dim <!ENTITY % commands " xupdate:variable | xupdate:insert-before | xupdate:insert-after | xupdate:append | xupdate:update | xupdate:remove | xupdate:rename "> <!ENTITY % instructions " xupdate:element | xupdate:attribute | xupdate:text | xupdate:processing-instruction | xupdate:comment "> <!ENTITY % qname "NMTOKEN"> <!ENTITY % template " (#PCDATA %instructions;)* "> <!ELEMENT xupdate:modifications (%commands;)*> <!ATTLIST xupdate:modifications id ID #IMPLIED version NMTOKEN #REQUIRED xmlns:xupdate CDATA #FIXED "http://www.xmldb.org/xupdate"; > <!ELEMENT xupdate:insert-before (%instructions;)*> <!ATTLIST xupdate:insert select CDATA #REQUIRED > <!ELEMENT xupdate:insert-after (%instuctions;)*> <!ATTLIST xupdate:insert select CDATA #REQUIRED > <!ELEMENT xupdate:append (%instructions;)*> <!ATTLIST xupdate:insert select CDATA #REQUIRED child CDATA #IMPLIED > <!ELEMENT xupdate:element %template;> <!ATTLIST xupdate:element name %qname; #REQUIRED namespace CDATA #IMPLIED > <!ELEMENT xupdate:attribute (#PCDATA)> <!ATTLIST xupdate:attribute name %qname; #REQUIRED namespace CDATA #IMPLIED > <!ELEMENT xupdate:text (#PCDATA)> <!ELEMENT xupdate:processing-instruction (#PCDATA)> <!ATTLIST xupdate:processing-instruction name NMTOKEN #REQUIRED > <!ELEMENT xupdate:update (#PCDATA)> <!ATTLIST xupdate:update select CDATA #REQUIRED > <!ELEMENT xupdate:remove EMPTY> <!ATTLIST xupdate:remove select CDATA #REQUIRED > <!ELEMENT xupdate:rename (#PCDATA)> <!ATTLIST xupdate:rename select CDATA #REQUIRED > <!ELEMENT xupdate:variable (#PCDATA)*> <!ATTLIST xupdate:variable name NMTOKEN #REQUIRED select CDATA #IMPLIED > <!ELEMENT xupdate:value-of EMPTY> <!ATTLIST xupdate:value-of select CDATA #REQUIRED > <!ELEMENT xupdate:if %template;> <!ATTLIST xupdate:if test CDATA #REQUIRED > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
