1. Physical and Logical Structure
SNU IDB Lab.

2. XML Documents 1 : structure
Peeping into XML document
at Physical view : Entity
at logical view : DTD

3. Peeping into XML document(1/5)
<?xml version=“1.0” standalone=“yes”?>
<GREETING>
Hello, XML!!
<!--this is greeting-->
</GREETING>
Mark-up
data
Text data는 문서의 가장 기본적인 정보. 이에 반해 마크업은 문서의 논리적 구조를 서술합니다.
다른 포맷에 비해 XML이 가진 큰 장점중의 하나는 문서의 마크업에서 실제의 데이터를 분리하는
작업이 명확하게 이루어진다는 것이죠.
마크업은 모든 주석과 문자reference, entity reference, CDATA section delimiter, 태그, 프로세싱 명령문,DTD
모두를 포함합니다.그 외 모든 것은 문자 data입니다.
Mark-up and character data

4. Peeping into XML document(2/5)
XML declaration
xml문서임을 선언.
<? 로 시작하여 ?>로 끝난다.
<? xml version=“1.0” standalone=“yes” ?>
<!DOCUMENT DATE [
<!ELEMENT DATE (#PCDATA)>
] >
DTD(Document Type Definition)
user가 사용할 tag를 정의한다.
여기서는 DATE tag를 정의.
<!--This is date -->
Comment : parser는 이를 무시.
<? xml version=“1.0” standalone=“yes” ?> 이건 XML선언문으로서 xml프로세싱명령어의 한 예입니다.
프로세싱의 명령어는 <?로 시작해서 ?>로 끝나죠. Xml선언은 version과 standalone의 두가지 attribute를 가집니다.
Version은 XML의 버전을 지정하고,
standalone은 이 문서가 자체로 완벽한 것인지 다른 파일을 불러와야 완전한 것인지
말해줍니다.
XML 의 comment는 <!— 로 시작하고 으로 끝나며, 그 안의 data는 XML processor에 의해 무시됩니다.
<DATE>
001224
</DATE>
Content
XML document : date.xml

5. Peeping into XML document(3/5)
Structure of XML document
physical structure :
allows components of the document, called entities
logical structure :
allows a document to be divided into named units and sub-units, called elements
XML 문서를 어떻게 보느냐에 따라 entity관점에서도 볼 수 있고, element관점에서 볼 수도 있습니다.
Xml의 특정한 부분을 담고 있는 물리적 저장단위를 entity라 하는데,
Entity는 문서하나일수도 있고, 파일하나 일수도 있고,database record일 수도 있고
그림파일일수도 있는 등, 다양한 아이템일 수 있습니다.
Element는 말 그대로 문서의 논리적인 구성단위 입니다. 태그로 감싸여져 있지요.
각 element는 자신을 나타내는 태그를 갖고 있습니다.
<book>abc</book>, <team>~~</team> 이런 것은 각각 book과 team이라는 element입니다.

6. Peeping into XML document(4/5)
Physical Structure
Logical Structure
Document
Unit
entities
(internal)
(separate)
Sub-unit
elements
그림 그대로에요. 뒷장을 보면 더욱 선명한 이해가 될 것입니다. 5

7. Peeping into XML document(5/5)
entity
<person>
<name> kim </name>
<ID>771224</ID>
<office> </office>
<phone>1830</phone>
<photo source=“k.jpg”/>
</person>
<person>
<name> kim </name>
<ID>771224</ID>
<office> </office>
<phone>1830</phone>
<photo source= />
</person>
“k.jpg”
element
왼쪽그림 : person 엘리먼트는 name엘리먼트와 ID엘리먼트, phone 엘리먼트, office엘리먼트, photo엘리먼트를
가지는군요. 이와 같이 엘리먼트는 한 엘리먼트속에 다른 엘리먼트를 내포할 수 있습니다.
오른쪽그림 : 이 문서는 그림파일 K.JPG를 내포하고 있습니다.
문서 엔티티속에 이미지 엔티티를 가지고 있는 셈입니다.

8. XML Documents 1 : structure
Peeping into XML document
at Physical view : Entity
at logical view : DTD
물리적으로 바라보면 XML 문서는 엔티티로 이루어져 있습니다.

9. Content of Physical structure
Entity
Figures of Document Entity
Defining an entity
Grammar in Declaring Entity
Examples of EntityDeclaration
URL format

10. Entity (1/3)
unit of physically isolating and storing any part of a document (정보저장단위)
Each unit of information is called an entity
<person>
<name> kim </name>
<ID>771224</ID>
<office> </office>
<phone>1830</phone>
<photo source= />
</person>
“k.jpg”
entity
entities
(internal)
(separate)
Physical Structure
Entity란 앞에서 말했듯이 문서중에서 물리적으로 독립되어 있는 정보저장단위입니다.
문서에 embed되어 있는 이미지 파일이나 오디오 파일, 비디오 파일등도 모두 엔티티입니다.
SNU
OOPSLA Lab.

11. Entity (2/3) Purpose of Entity contain all the information
(well-formed XML data , other text file, binary data…)
<person>
<name> kim </name>
<ID>771224</ID>
<office> </office>
<phone>1830</phone>
<photo source= />
</person>
“k.jpg”
Document entity
Entity의 존재 목적은 모든 종류의 정보를 저장하기 위함입니다.
정보를 담는 컨테이너, 엔티티.
Image entity

12. Entity (3/3) Internal Entity External Entity
해당 document 안에서 완전하게 정의되는 entity
External Entity
URL을 통해 알려진 외부의 source로부터 그들의 content를 받아 오는 entity
엔티티에는 두 가지 종류가 있습니다. 내부 엔티티와 외부 엔티티.
문서내에서 완벽하게 정의되는 엔티티를 내부 엔티티라 합니다. 문서 그 자체는 이미 하나의 엔티티이므로
모든 XML문서는 최소한 하나의 내부 엔티티를 갖고 있는 셈입니다.
반면에, 외부엔티티는 URL을 통해 알려진 다른 소스에서 그들의 컨텐트를 받아옵니다.
이 때 메인문서는 오직 실제의 컨텐트가 있는 URL로의 레퍼런스만 갖고 있습니다.

13. Figures of Document Entity
(no entities)
document entity
(main content)
document entity
(framework file) A A B
이름을 갖지 않는 유일한 엔티티가 바로 문서 엔티티 – document entitiy – 입니다. 문서엔티티는 문서 전체를 가리키는 data file 이죠.
간단한 경우로써, 오직 문서 자신이 유일한 엔티티인 경우가 있을 수 있습니다. 또, document의
주요 content를 포함하는 엔티티를 하나 가질 수도 있고. 극단적인 예로서는 다른 엔티티가 들어갈,
Frame work로서 다른 엔티티들의 위치를 잡아주는 역할만을 하는 frame work file 이 될 수도 있습니다.
아무 내용없어도, 그것 역시 엔티티라는 이야기 입니다. C D

14. Defining an entity
Entity must be defined before the first reference to them in the data stream
Declared in the DTD(Document Type Definition)
<!DOCTYPE DOCUMENT [
<!ENTITY
<!ENTITY TEXT “(#PCDATA)”>
]>
엔티티는 특별한 마크업 태그를 사용하여 정의되며, 이것을 엔티티 선언이라고 합니다. 엔티티선언은 document entity의 top부분에 반드시 와야 합니다.
엔티티선언은 엔티티의 존재를 선언하고, 이름을 부여하며, 그것이 가지고 있어야 할
Content에 대해 지정하여 주거나 파일을 직접 지정해 주기도 합니다.
위의 그림에서 은 엔티티 이름이고 그의 content입니다..
Entity definition in DTD

15. Example : EntityDeclaration(1/3)
Internal text entities
<!ENTITY XML “eXtensible Markup Language”>
<!ENTITY DemoEntity ‘The rule is 6” long.’>
Built-in entities (내장entity)
<!ENTITY sample “Use " and ‘as delimiters.”>
엔티티의 가장 간단한 형태는 internal text entity가 되겠습니다. 이런 타입의 엔티티는 문서의 제작자가
앞으로 쓸 어떤 ‘phrase’나 다른 text fragment에 대하여 예약어를 정하듯, 미리 정의를 해 두는 것입니다.
위의 예에서 앞으로 ‘eXtensible Markup Language’대신에 XML을 , ‘the rule is 6 long’ 대신에 DemoEntity를
쓸 모양이네요. 이런 것은 전체를 다 타이핑하기 귀찮거나 스펠링을 잘못 쓰게 될 일을 예방할 수 있습니다.
예를 들어 The &XML; format includes entities라고 쓰면 XML processor가 The eXtensible Markup Language라고
바꿔줍니다.
모든 XML processor는 몇 개의 내장entity를 가지고 있습니다. 문서 제작자는 그것들은 특별한 선언없이
갖다 쓸 수 있구요. 위의 list에 있는 <를 쓰려면 &li;를 대신 쓰면 되겠지요.
&li;
>
&
&apos;
"
for ‘<‘
for ‘>’
for ‘&’
for ‘ ’ ’
for ‘ ” ’;

16. Example : EntityDeclaration(2/3)
External text entities
<!ENTITY myent SYSTEM “/EMTS/MYENT.XML”>
<!ENTITY myent PUBLIC “-//MyCorp//ENTITY Syperscript Chars//EN”….>
Binary entities
<!ENTITY Jsphoto SYSTEM “/ENTS/Jsphoto.tif” NDATA “TIFF”>
External text entity의 위치는 system idextifier에 의해 제공됩니다. 위와 같이 ‘SYSTEM’ 키워드를 쓴 다음 파일의 위치를 큰 따옴표로 싸서 인용합니다. ‘SYSTEM’ 키워드 말고, ‘PUBLIC’키워드를 쓸 수도 있는데 이 public 키워드를 쓰면 좀 더 유연한 identifying이 가능합니다. 이 키워드를 쓰면 파일의 content에 대한 정보도 나타낼 수 있습니다.
파일의 카탈로그 정보를 포함시킬 수 있죠.
Binary 엔티티는 external text entity와 매우 비슷합니다. 선언도 비슷하게 이루어지는데,
한 가지 부가 정보를 써줘야 합니다. 이 binary파일이 어떤 포맷인지 뒤에 써주는 것입니다.
일단 파일 지정을 해 준다음에, NDATA키워드를 써주고, 파일 포맷을 써줍니다. 위를 보면 파일포맷으로서
Tiff가 써있죠? Jsphoto를 tiff 파일로 identify한 것이죠..

17. Example : EntityDeclaration(3/3)
URL format
<!ENTITY ent9 SYSTEM “entities/entity9.xml”> /xml/document.xml/entities/entity9.xml
<!ENTITY ent9 SYSTEM “../entities/entity9.xml”>
/xml/docs/document.xml/ entities/entity9.xml
xml
xml
위치에 따른 주소 지정. 이거야 dos시절의 기본입니다.
entity9.xml
document.xml
entity9.xml
document.xml
entities
docs
entities

18. XML Documents 1 : structure
Peeping into XML document
at Physical view : Entity
at logical view : DTD
이제 DTD를 공부하게 됐네요.

19. Content of Logical structure
Concepts
DTD Structure
Element Declaration
Attribute Declarations
Parameter Entities
Conditional Sections
Notation Declarations
DTD Processing Issues

20. Concepts of DTD(1/3) DTD(Document Type Definition)
An optional but powerful feature of XML
Comprises a set of declarations that define a document structure tree
XML processors read the DTD and check whether the document is valid and use it to build the document model in memory
Describes user’s own tag set as meta markup language
DTD는 XML의 가장 powerful한 특성임에 틀림없습니다. 우리는 새로운 우리만의 마크업 tag set 을 만들 수 있고, 이는 DTD를 통해 정의됩니다.
XML processor는 각 문서가 해당 DTD에 부합하는지 살핍니다.(validation, 유효성검사)
DTD는 문서타입정의(document type definition)을 나타내는 말입니다. DTD는 element , attribute , 문서에 포함된 entity의 목록 , 각 element와의 관계등을 알려주고,문서의 구조에 사용되는 규칙에 대해서도 서술합니다. DTD는 그 DTD가 서술할 문서를 포함하고있는 파일에 직접 포함될 수도 있고, 혹은 외부의 URL로 연결될 수도 있습니다. 이런 외부의 DTD는 여러 문서와 웹사이트에서 공유될 수도 있습니다. DTD는 애플리케이션들, 조직, 이익집단이 동의해서 마크업 표준을 고수하도록 강제할 수 있는 수단을 제공합니다.

21. Concepts of DTD(2/3) DTD describes..
Element , attribute , notation , relation between each elements
Establishes formal document structure rules
DTD는 문서타입정의(document type definition)을 나타내는 말입니다.
DTD는 element , attribute , 표기법, 문서에 포함된 entity의 목록 , 각 element와의 관계등을 알려주고,
문서의 구조에 사용되는 규칙에 대해서도 서술합니다.
DTD는 그 DTD가 서술할 문서를 포함하고있는 파일에 직접 포함될 수도 있고, 혹은 외부의 URL로 연결될 수도 있습니다.
이런 외부의 DTD는 여러 문서와 웹사이트에서 공유될 수도 있습니다.
DTD는 애플리케이션들, 조직, 이익집단이 동의해서 마크업 표준을 고수하도록 강제할 수 있는 수단을 제공합니다.

22. Concepts of DTD(3/3) Declare Vs. Define DTD define Valid Vs. Invalid
Declare  “This document is a concert poster”
Define  “A concert poster must have the following features”
DTD define
Element type + Attribute + Entities
Valid Vs. Invalid
Valid  conforms to DTD
Invalid  fail to conform to DTD
Well formed
XML Document
문서가 XML규약에 합치할 때 그것을 “well formed” 라고 합니다.
문서가 DTD 규약에 합치할 때 그것을 valid하다고 하죠. Well formed하나 valid하지 않은 많은 문서들도 있을 수 있습니다.
Valid XML Document

23. Valid & Invalid Documents
<GREETING>
various random text but no markup
</GREETING>
Invalid: anything else including
<sometag>various random text</sometag>
<someEmptyTag/>
위의 것은 valid한 문서와 invalid한 문서의 예를 보여줍니다. 둘다 XML 규약에 합치하므로 well formed 문서입니다.
그러나 아래의 것은 invalid입니다.
위의 노란 박스는 간단한 DTD의 한 예입니다. 일반적으로 DTD는 이거보다 훨씬 길고 복잡하죠.
이 경우 이 엘리먼트의 이름은 GREETING이 되겠네요. #PCDATA란 파싱된 문자데이타로서 마크업이 아닌 모든 텍스트를 말합니다.
Example:
<!DOCTYPE GREETING[
<ELEMENT GREETING (#PCDATA)>
]>

24. DTD structure DTD is composed of a number of declarations
ELEMENT (tag definition)
ATTLIST (attribute definitions)
ENTITY (entity definition)
NOTATION(data type notation definition)
DTD can be stored in an external subset or an internal subset
DTD는 ELEMENT (tag definition) , ATTLIST (attribute definitions) , ENTITY (entity definition) , NOTATION(data type notation definition) 등의 여러 개의 선언으로
구성됩니다. 문서에 나타날 element , attribute , enetity , 표기법등을 미리 선언해놓는 것입니다. 이 DTD와 어긋나면 invalid문서가 됩니다.
한편 DTD는 해당 문서내에 있을 수도 있고, 파일 밖의 외부 URL에 있을 수도 있습니다.

25. Internal and External Subset(1/3)
Internal subset
Form :
<!DOCTYPE … [
<!-- Internal Subset --> …
]>
Pros
Easy to write XML
Cons
Editing two files without moving
Other document can’t reuse without copying internal subset
DTD가 해당 문서 내에 있는 경우 입니다. 이 경우 DTD는 문서의 top 부분에 와야 합니다.
<!DOCTYPE GREETING[<ELEMENT GREETING (#PCDATA)>]> 하는 식으로 별다른 거 없이 그냥 쓰면 됩니다.
이런 internal subset의 장점은 XML문서를 write하기 편하다는 것입니다. 그러나 다른 문서들과 DTD를 공유한다거나 할 때는 많이 불편합니다.

26. Internal and External Subset(2/3)
better to use external DTDs
Reason why?
Many benefits
document management
updating
editing
Few reasons
If you use an external DTD, you can use public DTDs(capability)
External DTDs provide for better document management
External DTDs make it easier to validate you document
External subset은 DTD가 해당문서의 바깥에 있는 것을 의미합니다. 보통은 이런 방식을 많이 쓰고, 이것이 더 편한데 이유는 다음과 같습니다.
우선 일단 DTD와 문서가 분리되어 있으므로, 문서관리가 쉽고, 업데이트나 편집하기도 편리합니다. 또 공유되어 있는 양질의 훌륭한 DTD들을 갖다 쓸 수 있죠. 대개 공유되어 있는 그런 DTD가 더 나은 품질의 문서를 약속합니다. 또 사용자가 DTD를 만들지 않아도 되니까 편한 점도 있지요.

27. Internal and External Subset(3/3)
full parsing path
internal
external
Internal subset
external subset
왼쪽 그림은 전형적인 internal DTD와 external DTD를 가리킵니다.
오른쪽그림에서: 문서는 일부의 dtd는 자신 안에 두고 일부는 외부에서 갖다 쓸 때도 있습니다. 문서내의 standlone 속성이 XML processor가 외부의 DTD도 탐색해야 하는지 아닌지 알려줍니다.

28. Element Declarations
Used to define a new element, specify its allowed content and gives the name and content model of the element
Each tag must be declared in a <!ELEMENT> declaration.
The content model uses a simple regular expression-like grammar to precisely specify what is and isn't allowed in an element
ELEMENT Type declaration ‘<!ELEMENT’ S Name S Contentspec S? ‘>’

29. Content Specifications
ANY
#PCDATA
Sequences
Choices
Mixed Content
Modifiers
Empty

30. ANY
A SEASON can contain any child element and/or raw text (parsed character data)
Rarely used in practice, due to the lack of constraint on structure it encourages.
<!ELEMENT SEASON ANY>

31. #PCDATA Parsed Character Data; i.e. raw text, no markup
Represent normal data and preceded by the hash-symbol, ‘#’, to avoid confusion with an identical element name, when used within a model group ( for example, ‘(#PCDATA | PCDATA)’)
<!ELEMENT YEAR (#PCDATA)>

32. Use of #PCDATA in XML Valid: Invalid: <YEAR>1999</YEAR>
<YEAR>1999 .E.</YEAR>
<YEAR>
The year of our Lord one thousand, nine hundred, and ninety-nine
</YEAR>
<YEAR>
<MONTH>January</MONTH>
<MONTH>February</MONTH>
<MONTH>March</MONTH>
<MONTH>April</MONTH>
<MONTH>May</MONTH>
<MONTH>June</MONTH>
<MONTH>July</MONTH>
<MONTH>August</MONTH>
<MONTH>September</MONTH>
<MONTH>October</MONTH>
<MONTH>November</MONTH>
<MONTH>December</MONTH>
</YEAR>

33. Child Elements
To declare that a LEAGUE element must have a LEAGUE_NAME child:
<!ELEMENT LEAGUE (LEAGUE_NAME)>
<!ELEMENT LEAGUE_NAME (#PCDATA)>

34. Sequences(1/2)
Separate multiple required child elements with commas; e.g.
One or More Children +
<!ELEMENT SEASON (YEAR, LEAGUE, LEAGUE)>
<!ELEMENT LEAGUE (LEAGUE_NAME, DIVISION, DIVISION, DIVISION)>
<!ELEMENT DIVISION_NAME (#PCDATA)>
<!ELEMENT DIVISION (DIVISION_NAME, TEAM+)>

35. Sequences(2/2) Zero or More Children * Choices
<!ELEMENT TEAM (TEAM_CITY, TEAM_NAME, PLAYER*)>
<!ELEMENT TEAM_CITY (#PCDATA)>
<!ELEMENT TEAM_NAME (#PCDATA)>
<!ELEMENT PAYMENT (CASH | CREDIT_CARD)>
<!ELEMENT PAYMENT (CASH | CREDIT_CARD | CHECK)>

36. Grouping With Parentheses
Parentheses combine several elements into a single element.
Parenthesized element can be nested inside other parentheses in place of a single element.
The parenthesized element can be suffixed with a plus sign, a comma, or a question mark.
<!ELEMENT dl (dt, dd)*>
<!ELEMENT ARTICLE (TITLE, (P | PHOTO |GRAPH | SIDEBAR | PULLQUOTE | SUBHEAD)*, BYLINE?)>

37. Mixed Content Both #PCDATA and child elements in a choice
#PCDATA must come first
#PCDATA cannot be used in a sequence
<!ELEMENT TEAM (#PCDATA | TEAM_CITY | TEAM_NAME | PLAYER)*>
Empty elements
<!ELEMENT BR EMPTY>

38. Attribute Declarations
Consider this element:
It is declared like this:
<!ATTLIST Element_name Attribute_name Type Default_value>
<GREETING LANGUAGE="Spanish">
Hola!
</GREETING>
<!ELEMENT GREETING (#PCDATA)>
<!ATTLIST GREETING LANGUAGE CDATA "English">

39. Multiple Attribute Declarations
Consider this element
With two attribute declarations:
With one attribute declaration
Indentation is a convetion, not a requirement
<RECT LENGTH="70px" WIDTH="85px"/>
<!ELEMENT RECTANGLE EMPTY>
<!ATTLIST RECTANGLE LENGTH CDATA "0px">
<!ATTLIST RECTANGLE WIDTH CDATA "0px">
<!ATTLIST RECTANGLE LENGTH CDATA "0px"
WIDTH CDATA "0px">

40. Attribute Types CDATA ID IDREF IDREFS ENTITY ENTITIES NOTATION NMTOKEN
NMTOKENS
Enumerated

41. CDATA Most general attribute type
Value can be any string of text not containing a less-than sign (<) or quotation marks (")

42. ID Value must be an XML name
May include letters, digits, underscores, hyphens, and periods
May not include whitespace
May contain colons only if used for namespaces
Value must be unique within ID type attributes in the document
Generally the default value is #REQUIRED

43. IDREF Value matches the ID of an element in the same document
Used for links and the like
IDREFS
A list of ID values in the same document
Separated by white space

44. ENTITY
Value is the name of an unparsed general entity declared in the DTD
ENTITIES
Value is a list of unparsed general entities declared in the DTD
Separated by white space

45. NOTATION Value is the name of a notation declared in the DTD
<!NOTATION Tex SYSTEM “..\TEXVIEW.EXE”>
<!ENTITY Logo SYSTEM “LOGO.TEX” NDATA Tex> 1 3 4 2
TEXVIEW.EXE
LOGO.TEX

46. NMTOKEN Value is any legal XML name NMTOKENS
Value is a list of XML names
Separated by white space

47. Enumerated Not a keyword
Refers to a list of possible values from which one must be chosen
Default value is generally provided explicitly
<!ATTLIST P VISIBLE (TRUE | FALSE) "TRUE">

48. Attribute Default Values
A literal string value
One of these three keywords
#REQUIRED
#IMPLIED
#FIXED

49. #REQUIRED No default value is provided in the DTD
Document authors must provide attribute value for each element
<!ELEMENT IMG EMPTY>
<!ATTLIST IMG ALT CDATA #REQUIRED>
<!ATTLIST IMG WIDTH CDATA #REQUIRED>
<!ATTLIST IMG HEIGHT CDATA #REQUIRED>

50. #IMPLIED No default value in the DTD
Author may(but does not have to) provide a value with each element

51. #FIXED Value is the same for all elements
Default value must be provided in DTD
Document author may not change default value
<!ELEMENT AUTHOR EMPTY>
<!ATTLIST AUTHOR NAME CDATA #REQUIRED>
<!ATTLIST AUTHOR CDATA #REQUIRED>
<!ATTLIST AUTHOR EXTENSION CDATA #IMPLIED>
<!ATTLIST AUTHOR COMPANY CDATA #FIXED "TIC">

52. Example of Internal DTDs
<?xml version="1.0"?>
<!DOCTYPE GREETING [
<!ELEMENT GREETING (#PCDATA)>
]>
<GREETING>
Hello XML!
</GREETING>

53. Internal DTD Subsets
Internal declarations override external declarations
<?xml version="1.0"?>
<!DOCTYPE GREETING SYSTEM "greeting.dtd" [
<!ELEMENT GREETING (#PCDATA)>
]>
<GREETING>
Hello XML!
</GREETING>