RE: Content-in-RDF stable draft

Hi Johannes,

> > - There's no possibility of specifying the encoding of the TextContent.
> On the other hand if we provide encoding properties for both (XMLContent
> already has its own)  we will be suffering the same double-enconding
> problems we had
> discussed before.
> 
> The xmlEncoding property specifies the _declared_ character encoding (in
> the XML declaration), not the _used_ encoding. Text content in general
> has no character encoding declaration.

Does it then make any sense to keep a character encoding that doesn't match the real one? Additionally the transcodification problem still remains.


> >[...]
> > - We have XMLContent and TextContent, so it is supposed that for html
> (not xhtml) we may use TextContet.
> 
> Yes.
>
> > Although is true that html is usually treated as plain text, do you
> think we may include a SGMLContent? (even just as a plain empty container)
> 
> What's the benefit of having SGMLContent?

For example you know you're dealing with SGMLContent (e.g. HTML) without having to scrutinize the content itself if you want to distinguish it from whatever other non-structured plain text format (e.g .txt).

 
> > Editorial staff:
> >
> > - May the XMLContent class be a subclass of TextContent? In fact it is a
> class of text content, isn't it?
> 
> Then every resource of type XMLContent would have to provide a chars
> property as well, the value (object) for which is not necessarily
> available.

That's true, an abstract TextContent class may be necessary with PlainText, XMLContent, SGMLContent... subclasses. Or, even better, we may keep it as is :o)


> > - The "Extensions" section reads "Classes to specify the Document Object
> Model (DOM) of XML documents". DOM core is applicable to XML, HTML or even
> CSS documents [1],
> 
> Although the referenced note says so, a CSS "document" has no nodes, no
> elements, no PIs, etc. So DOM Core does _not_ apply to CSS.

Maybe not the core as is, but it's apparently clear that DOM does apply to CSS [2] to certain extend. Don't see any comment regarding HTML so I suppose you agree on that.

 
> > as they are very important formats for our uses cases I think we should
> reword this phrase to include them.
> 
> BTW, we talked about using XMLContent also for storing the DOM created
> from HTML.

I recall the discussion about the possibility of a DOMContent structure, but not about reusing XMLContent for this :o/

 
> > - The xmlRest definition reads: "Property representing as an XML Literal
> the part of the XML following the document type declaration if there is a
> document type declaration, or the part following the XML declaration if
> there is no document type declaration."
> 
> Comments, PIs and the root element could be mentioned here.

In fact I didn't finish my comment on the last message. What I meant is that I think the definition is not complete nor determinative because, AFAIR, the DTD and XML declarations are both optional, so if you don't have any of them, what's then the xmlRest?

 
> > - The definition of xmlLeadingMisc looks too much straightforward, even
> taking into consideration that XML knowledge is required. Reference to the
> allowed components (comments or PI) may be better.
> 
> I agree, that mentioning comments and PIs would be useful, but
> "following the XML declaration and preceding the document type
> declaration" is necessary to show that only these comments and PIs go
> here.

Then, we both agree :o)

 
> > [1] - [http://www.w3.org/TR/2004/NOTE-DOM-Requirements-
> 20040226/#general-requirements]

[2] - [http://www.w3.org/TR/DOM-Level-2-Style/]
 

Regards,
 CI.

_________________

Carlos Iglesias

Fundación CTIC
Parque Científico-Tecnológico de Gijón
33203 - Gijón, Asturias, España

teléfono: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org

Received on Monday, 25 February 2008 17:13:06 UTC