Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!deccrl!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.text.sgml Subject: Re: Data attribute specification delimiter recognition mode Message-ID: <1991-128-78110@uunic.uu.no> Date: 9 May 91 22:31:12 GMT References: Sender: enag@ifi.uio.no (Erik Naggum) Distribution: comp Organization: Naggum Software, Oslo, Norway Lines: 114 In-Reply-To: jjc@jclark.UUCP's message of 8 May 91 14: 03:49 GMT In , James Clark writes: [What is the] delimiter recognition mode [359] supposed to be when parsing an attribute specification list [327:17] occurring in a data attribute specification [428:20]? Good question. I have to make up an example to be able to answer your question. Given consider the element In this (contrived) example, the entity is accessed within a start- tag, and the delim data attribute is probably parsed at that point. This is, as far as I read it, the only time an external entity with a notation should be referenced, as it would make nil sense (semanti- cally) to reference an external entity with a data content notation by itself. Consider the case &formula1; What could this possibly mean? The entity is referenced by and fed to the parser, not the application, and the parser doesn't know what to do with a notation. Somehow, the notation information (and its data attributes) have to be communicated to the application, and a general entity reference can't do that. (I have some questions relating to the comment in 10.5.5 [401:9] that a data entity may be able to reference other data entities or subdocuments _in_its_own_ _notation_. How?) I would still think that this is an oversight of the amendment, and that something should be said about data attributes in general entity references in replaceable character data [343:1] and other content [320:14]. It's also somewhat contorted to think of the data attributes as applying to and being parsed in the start-tag where the entity is referenced. I'll file a defect report with ISO. I have a similar problem with result attribute specifications [446:8] and link attribute specifications [443:16]. The answer here also concerns when parsing of the attribute specification list occurs, but I don't think an oversight of the amendment in involved. Given ]> ]> ]> the document instance data becomes data as the source document link attribute definition list is applied, which becomes data after link processing. That is, the attribute specification lists are parsed when the start-tag is encountered or generated, in that start-tag, i.e. in TAG recognition mode. In other words, the attr def list is only stored for later parsing when the start-tag to which is applies is parsed. Whew! This took me a while to answer. (In fact, almost 8 hours, including leafing back and forth in The SGML Handbook, ISO 8879 and ISO 8879A1, to check when something was added, trying to find all references to data attributes and notation, tracing down the syntax productions (thanks to my package for GNU Emacs, this was relatively painless) to find where /vi/ was referenced, etc. I think I've got it right, but I'm not at all certain about when data attributes are parsed. It only makes a lot of sense to do it within the start-tag which references the entity which has the notation attribute and the associated data attribute specification, and nil sense to do it for random general entity references outside start-tags. I'm somewhat confused by the first sub-item of item k in attachment 1 to ISO/IEC JTC 1/SC 18/WG 8/N 1035 (Appendix B in The SGML Handbook) [593:1], which seems to address general entity references to data entities, but not explicitly.) I hope it's been as rewarding to read as it was to write it. -- [Erik Naggum] Professional Programmer Naggum Software Electronic Text 0118 OSLO, NORWAY Computer Communications +47-2-836-863