[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SML] Whether to support Attribute or not?
I understand the problem better after reading other people's responses. What threw me was the analogy to object data and behavior, which I don't think is the right analogy. In each of these example elements <lineitem><model>XYZ</model><quantity>3</quantity></lineitem> <lineitem quantity="3"><model>XYZ</model></lineitem> <lineitem quantity="3">XYZ</lineitem> 'lineitem' has two properties: model and quantity. It happens that in the last example the model is not labelled 'model'. The label is missing, since strictly speaking XYZ is not the lineitem. If we throw away the quantity attribute we are left with... <lineitem>XYZ</lineitem> XYZ may indeed represent the line item, but we could have chosen a more specific word... <model>XYZ</model> I'd argue that if an element has attributes in addition to text content, then the attributes together with the content define the element, and the content must therefore be yet one more property of the element. The property simply has not been named. You might consider that a shortcoming of XML. By allowing attributes it allows elements to have unnamed properties. I'm having trouble interpreting this as an advantage that attributes give. Were there never attributes, every property would have a label. (Unless there is mixed content, which prompts my next thread...) I think the solution for SML/XML conversion is give this property an explicit name. At 04:21 AM 11/28/1999 -0500, Clark C. Evans wrote: >On Fri, 26 Nov 1999, Don Park wrote: >> I believe it is now time to address the question of >> whether Attribute should be supported in SML or not. > >Summary: > > Attributes cannot be eliminated without > providing a suitable replacement. > >Discussion: > > The reason why SGML/XML/SML is so powerful is > that it accurately reflects the dual nature > of reality. Code has two aspects -- it is > edited as data and run as instructions. > > This pattern is recursive. Witness yet another > compiler ("yacc"), it is code which instructs the > generation of code. > > XML is powerful beacuse it recognizes that there are > _always_ two simotanenous contexts that must be > distinguished: data and markup. > > Attributes are the result of applying this same > pattern recursively on the markup itself. Thus, a > given tag can have instructions (the attribute) and > data for those instructions (the attribute's value). > > Attributes therefore, allow a second order approximation > to the recursive pattern: > > [Attribute] > / > [Markup] > / \\ > / [Value] > > [Document] > / [Attribute] > \\ [Markup] > \\ / \\ [Value] > [Content] > \\ > [Content] ... > > > Unfortunately, as pointed out on this list many, many > times -- by having a different syntax, attributes do > not allow for further recursion. Thus, there is an > entire realm of reality which cannot be described > using XML, since attributes cannot have children. > > Thus, I really doubt that it is possible to have > a meaningful markup language without attributes -- > however, finding a recursive replacement would > be very good. > > Consider: > > <element att="val"> <content/> </element> > > If attributes were eliminated, this would be mapped to: > > <element> <att>val</att> <content/> </element> > > > Possibility #1: > > Use a hard-coded namespace, > > <element> <attribute:att>val</attribute:att> <content/> </element> > > Possibility #2: > > Use a marker, > > <element> <$att>val</$att> <content/> </element> > > Possibility #3: > > Use another type of brackets, > > <element> {att}val{/att} <content/> </element> > > Possibility #4: > > Use a divider, > > <element> <att>val</att> <|> <content/> </element> > > > In any case, replacing the attribute mechanism with > one that allows for recursion would allow for > stuff like: > > <para alt="<b>alt</b>"> para </para> > > To be legally expressed (using syntax #4): > > <para> <alt><b>alt</b></alt> <|> para </para> > > >Hmm. Thoughts? > >Clark > > > > > > >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/ and on CD-ROM/ISBN 981-02-3594-1 >To unsubscribe, mailto:majordomo@i... the following message; >unsubscribe xml-dev >To subscribe to the digests, mailto:majordomo@i... the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@i...) > -- Joe Lapp (Looking for some good people to help design Senior Engineer and build the Internet's business-to-business webMethods, Inc. XML infrastructure. We are 100% Java.) jlapp@w... http://www.webMethods.com 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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
|